numerics question, ancient bug long fixed?

Accelerated Computing HPC Compilers Legacy PGI Compilers
#1

Hello,

I run a fortran90 landscape evolution model on OS X, have been doing so since the first gen Mac Pros with the earliest PGI compilers for OS X. I’ve seen one niggling issue with an executable compiled I believe with 8.0-4, 8.0-5, or 8.0-6, using the quick-start optimizing flags “-fast -Mipa=fast”.

In one pair of functions which mix materials with two different erosion parameters the developer catches nonphysical cases of negative erosion and negative parameter values passed into the function, defaults the bad values to the default input parameter values, and issues a warning that the nonphysical values were caught.

The locations of these occurrences suggests the flow is encountering a sudden slope reversal from roughness in the digital terrain. I’m assuming some sort of overflow or underflow was happening.

With no optimization, the nonphysical values never occur, and the resulting terrain is exactly that predicted by the more optimized version. I have never been able to replicate the problem with any level of optimization with later releases, nor with gfortran on the original MacPro1,1, a 3-year old laptop, and the latest MacPro6,1 nor with g95 on older Mac Pros. All executables compiled with the later PGI releases predict the same terrain; gfortran predicted “close enough” if not exact matches. That particular executable does carry the errors to Mac Pros and laptops with different CPUs.

It doesn’t appear that those flags introduce anything particularly dangerous. Would this be chalked up to a subtle compiler bug from back in the day? If so what sort of bug would be most suspect? I would just like to be able to say something reasonable if asked.

Thanks,
Kelly

#2

Hi Kelly,

Would this be chalked up to a subtle compiler bug from back in the day?

Given the evidence, it’s certainly plausible. Of course without investigation, it’s impossible to tell for sure.

If so what sort of bug would be most suspect?

I looked through all of our 8.0 bug reports. I see only one report of incorrect answers when optimization is applied and it only occurs when a converting single to double precision Cray pointer (TPR#15761). For example:

subroutine sub( n)
 common /aa/aa(10000)
 real*8 aa
 pointer(pb,bb)
 real*4 bb(100000)
 do i = 1, 800
 aa(i) = dble(bb(i))   ! << Here
 enddo
 end

So if you use Cray pointers, that could be it. Otherwise, I’m not sure.

  • Mat
#3

Thanks Mat,

Cray pointers weren’t used, so that shouldn’t be associated with the problem. Since it has never occurred with any other releases or without optimization, nor with 64-bit gfortran, I’ll claim it was a likely subtle compiler bug.

The bad input values that trigger the warning in the functions result from a predictor-corrector routine solving a stiff system of equations, and the sudden rise the flow sees is problematic anyway. Luckily this all happens far enough outside our region of interest, which is why I never spent the effort to clean up the input terrain in the affected areas.

Cheers,
Kelly