Bugreport - "0.0 - n(4)" vs "-n(4)"

[gtauriello]

The following code produces a wrong result using ifort (IFORT) 11.1 20100203 (that is 11.1.084):

[fortran]PROGRAM test

    IMPLICIT NONE

    REAL :: nn(6), inn(25), bla(24)
    
    nn = 0.
    nn(1) = 1.
    nn(4) = 1.
    
    !identity - nn^transpose
    inn(1) = 1. - nn(1)
    inn(2) = 1. - nn(2)
    inn(3) = 1. - nn(3)
    inn(4) = 0. - nn(4)
    inn(5) = 0. - nn(5)
    inn(6) = 0. - nn(6)
    
    bla(1) = 1. - nn(1)
    bla(2) = 1. - nn(2)
    bla(3) = 1. - nn(3)
    bla(4) = -nn(4)
    bla(5) = -nn(5)
    bla(6) = -nn(6)
    
    PRINT '(A,F8.2,F8.2,F8.2)', 'nn = ', nn(1), nn(6), nn(5)
    PRINT '(A,F8.2,F8.2)', '             ', nn(2), nn(4)
    PRINT '(A,F8.2)', '                     ', nn(3)
    PRINT '(A,F8.2,F8.2,F8.2)', 'inn = ', inn(1), inn(6), inn(5)
    PRINT '(A,F8.2,F8.2)', '              ', inn(2), inn(4)
    PRINT '(A,F8.2)', '                      ', inn(3)
    PRINT '(A,F8.2,F8.2,F8.2)', 'bla = ', bla(1), bla(6), bla(5)
    PRINT '(A,F8.2,F8.2)', '              ', bla(2), bla(4)
    PRINT '(A,F8.2)', '                      ', bla(3)
    
END
[/fortran]

As one can easily see, bla and inn should have the same results. Yet, for inn I get 0-nn as a result. Here is the output of the program:

[bash]nn =     1.00    0.00    0.00
                 0.00    1.00
                         0.00
inn =    -1.00    0.00    0.00
                  0.00   -1.00
                          0.00
bla =     0.00    0.00    0.00
                  1.00   -1.00
                          1.00[/bash]

I am working on a 64bit Mac OS X 10.6.5 with an Intel Core i5. Unfortunately, I have no access to newer versions of ifort and so I cannot check whether it was fixed in the more recent releases. I did try it with 11.1.067 and there the result is correct.

[mecej4]

I don't have a Macintosh, so this is a guess. See if this post is applicable and try the workaround of adding -use_asm as an option to take care of the problem.

[Kevin_D_Intel]

This does not appear related to the earlier issue mecej4 cited.It also reproduces with our latest release and at all opt-levels.I will report this to our Developers and update when I learn more.

[gtauriello]

Thank you very much for your answer. I did not know about this incompatibility.
I have Xcode 3.2.3 and when I tried it with ifort 11.1.067 I did it on a machine with Xcode 3.2.1. On my own machine it did not help to switch to 11.1.067. Your suggestion to add "-use_asm" on the other hand did fix the issue for me. Until I can get my hands on the latest ifort-Version (I need to go through the university to get it), I will try to use that workaround...

PS: I had tried it with no optimizations ("-O0") earlier and that "fixed" the issue too...

[Piergiorgio_Alotto]

on my macbook pro with ifort 11.1.084 I get wrong results with optimization set at -O1 -O2 etc.
I get correct results at -O0
hope this helps yout as a temporary workaround

[Kevin_D_Intel]

After some additional testing, I found that I misspoke earlier. The issue is reproducible using 11.1.084 and it does appear related to the issue mecej4 cited. My apologies. It does not reproduce at -O0.

As per the cited article, you may also work-around this issue with 11.1.084 and adding: -use-asm

The issue is also fixed in the 11.1.089 update.

Sorry again for the earlier misinformation.

[gtauriello]

I was actually curious on what would happen in C++ for it (using icc (ICC) 11.1 20100203) and here we go. The following C++ code also gets wrong results:

[cpp]#include 

int main()
{
    double nn[6], inn[6], bla[6];
    
    nn[0] = 1.0;
    nn[1] = 0.0;
    nn[2] = 0.0;
    nn[3] = 1.0;
    nn[4] = 0.0;
    nn[5] = 0.0;
    
    inn[0] = 1.0 - nn[0];
    inn[1] = 1.0 - nn[1];
    inn[2] = 1.0 - nn[2];
    inn[3] = 0.0 - nn[3];
    inn[4] = 0.0 - nn[4];
    inn[5] = 0.0 - nn[5];
    
    bla[0] = 1.0 - nn[0];
    bla[1] = 1.0 - nn[1];
    bla[2] = 1.0 - nn[2];
    bla[3] = -nn[3];
    bla[4] = -nn[4];
    bla[5] = -nn[5];
    
    std::cout << "n =t" << nn[0] << "t" << nn[5] << "t" << nn[4] << std::endl;
    std::cout << "   t t"               << nn[1] << "t" << nn[3] << std::endl;
    std::cout << "   t t t"                             << nn[2] << std::endl;
    
    std::cout << "bla =t" << bla[0] << "t" << bla[5] << "t" << bla[4] << std::endl;
    std::cout << "     t t"                << bla[1] << "t" << bla[3] << std::endl;
    std::cout << "     t t t"                               << bla[2] << std::endl;
    
    std::cout << "inn =t" << inn[0] << "t" << inn[5] << "t" << inn[4] << std::endl;
    std::cout << "     t t"                << inn[1] << "t" << inn[3] << std::endl;
    std::cout << "     t t t"                               << inn[2] << std::endl;
	
	return 0;
}
[/cpp]

Correct result (generated with g++ or icc -O0 ... or icc -use_asm ...):

[bash]n =	1	0	0
   	 	0	1
   	 	 	0
bla =	0	0	0
     	 	1	-1
     	 	 	1
inn =	0	0	0
     	 	1	-1
     	 	 	1
[/bash]

Wrong result (generated with icc):

[bash]n =	1	0	0
   	 	0	1
   	 	 	0
bla =	0	0	0
     	 	1	-1
     	 	 	1
inn =	0	0	0
     	 	0	0
     	 	 	0
[/bash]

[Kevin_D_Intel]

Yes. The root-cause involves the GNU linker (ld) handling of a specific form of symbol namewhich both our C/C++ and Fortran compilers may use.The resultwas both C/C++ and Fortran programs can be affected. Our compilers (starting with 11.1.089) were changed to avoid using the problematic form of symbol name.

I also confirmed this C++ case fails with C++ 11.1.084 and is fixed C++ 11.1.089 update.