Compiler optimization bug - V7.0-3 (and 6.1)

Hi!

I have the following problem … when compiling this code as listed - nothing is left out (however it is part of a small subroutine in a MUCH larger program):

Beta = ASIN (sqrt(random_value_1))
write(0,) ‘beta1:’,beta,random_value_1
Beta = ASIN (sqrt(random_value_1))
write(0,
) ‘beta2:’,beta,random_value_1

pgf95 -O -Mlist -Mbyteswapio -tp k8-32

I get the following output over N iterations - the first time gives correct values - every other iteration gives an NaN the first time Beta is calculated - despite the fact the statements are identical.

beta1: 0.4755054 0.2095697
beta2: 0.4755054 0.2095697

beta1: NaN 0.7170435
beta2: 1.009910 0.7170435

beta1: NaN 3.9387934E-02
beta2: 0.1997904 3.9387934E-02

If I compile with -
pgf95 -g -Mlist -Mbyteswapio -Mdclchk -Mdepchk -Minform=inform -Minfo -Mbounds -tp k8-32

The output is correct on each iteration - no NaNs appear.

Since unoptimized code gives the correct output I am tempted to consider a compiler optimization bug since the bounds checking does not indicate any memory issues when the code runs correctly - but maybe I am missing something - I am running 64bit Redhat Enterprise Linux 4 on an AMD64 X2 4600+. The issue does not seem to arise on a Intel D840 with 32 bit RHEL4 and only 32 bit compilers installed. I can not run the 64 bit compiler because of a different compiler issue with data corruption I haven’t been able to track down. Could this be a library issue of some sort? The code has run perfectly well in the past - I don’t know what could have changed in the current circumstances except perhaps one of the Redhat libraries. Any suggestions would be appreciated.

Thanks,

David

I have investigated this further - still using the -tp k8-32 flag -

Compiled with -O -g - the NaN problem still exists
Compiled with -O1 - the problem goes away
Compiled with -O2 - the NaN problem exists
Compiled with -O3 - the NaN problem exists

Apparently lower levels of optimization - either none or -O1 either do not have the issue or somehow hide it.

Can anyone suggest any debug options or anything else I can try to track this down further? Both the sqrt and asin functions are compiler built-ins - I can’t see how beta in the code sample I have above can obtain an NaN value unless there is an issue with the data passed to the built in functions or the subsequent store of the result.

By the way - it may not have been clear in my initial example - if I only have one of the beta lines - the code generates the NaN result - it doesn’t work - which is what I was debugging when I ran across this issue.

Cheers,

David

Hi David,

I tired to recreate the issue here but was unable (see below). Can you post a small example which illustrates the problem? If the problem only occus in the original code, can you send a report to PGI customer service (trs@pgroup.com) with information on how we can obtain a copy?

Thanks,
Mat

% cat tmp.f90
N=4
random_value_1 = 0.2095697
DO I=0,N
   Beta = ASIN (sqrt(random_value_1))
   write(0,*) 'beta1:',beta,random_value_1
END DO

END
% pgf90 -V7.0-3 -O -Mlist -Mbyteswapio -tp k8-32 tmp.f90
% a.out
 beta1:   0.4755054       0.2095697
 beta1:   0.4755054       0.2095697
 beta1:   0.4755054       0.2095697
 beta1:   0.4755054       0.2095697
 beta1:   0.4755054       0.2095697