I have a case where PGI Fortran 13.5 on certain hardware gives sigfpe when it should not do so. I have a 200-line reproducer but it involves reading a 40K unformatted file, so I don’t think I can post that here.
The problem comes when PGI Fortran 13.5 sees an exponential function with a double-precision argument and emits a call to __fsd_exp. This library routine has as its first line the SSE instruction
comiss %xmm0,%xmm0
The comiss instruction compares scalar single-precision floating-point values and raises an exception if either operand is NaN. But with a double-precision argument, looking at single-precision pieces can give a NaN. In my case xmm0[0], treated as hex64, is 0xC017F03AFFD26E29; when treated as float64 it is -5.984600064486167; when treated as float32 I see xmm0[0]=-nan and xmm0[1]=-2.37403727. So the code gets SIGFPE.
I am compiling with -Ktrap=fp; if I remove this flag the SIGFPE is ignored, but that is not an option for the big original code.
This problem occurs with PGI Fortran 13.5 on AMD Opteron 2352 and on Intel Harpertown (Xeon 5472). It does not occur on Sandy Bridge (Xeon E5-2670). On Sandy Bridge, the exponential becomes a call to __fsd_exp_vex, which has as its first line
vcomisd %xmm0,%xmm0
which looks like a double-precision vector instruction.
With PGI Fortran 13.2 on the Opteron 2352, the first instruction in __fsd_exp is
comisd 0xFFFFFFFFFFFF8FE8(%rip),%xmm0
which looks like a double-precision vector instruction. There is no problem with PGI Fortran 13.2, the problem is with PGI Fortran 13.5 on certain hardware.
I would like to know if there is a workaround for this that does not involve omitting “-Ktrap=fp”.
I can send the reproducer and data file via e-mail if necessary.