I’m evaluating the v6.0-4 pgf95 compiler and when I compile and run my numeric inquiry test code, I found I was getting floating point exceptions (I use the -Ktrap=ovf option). I tracked it down to the EXPONENT intrinsic always giving a result of -1022 for single precision arguments in a particular context. Some output of my test code (with the ovf option turned off) is shown below:
Single kind type : 4 Number = 1.2345679000000E-16 1.2345678000000E+16 -------------------------------------------------------------- EXPONENT() = -1022 -1022
As you can see, the reported EXPONENT() values are incorrect (my output also uses 1.2345679000000E-01, 1.2345679000000E+01, and 9.9999998000000E-03 as arguments and they also produce -1022 output for EXPONENT).
I tried to replicate this error in a really simple program, but could not. My test code declares some test numbers:
INTEGER, PARAMETER :: Single = SELECTED_REAL_KIND(6) INTEGER, PARAMETER :: N_TEST_NUMBERS = 5 REAL( Single ), PARAMETER, DIMENSION( N_TEST_NUMBERS ) :: SP_TEST_NUMBER = & (/ 1.234567890123456e-16_Single, & 1.234567890123456e-01_Single, & 1.234567890123456e+01_Single, & 1.234567890123456e+16_Single, & 0.01_Single /)
and a structure to hold the result:
TYPE :: SP_NI_type REAL( Single ) :: Number INTEGER :: Exponent END TYPE SP_NI_type
I then loop over the test numbers calling the intrinsics:
TYPE( SP_NI_type ), DIMENSION( N_TEST_NUMBERS ) :: SP_NI DO i = 1, N_TEST_NUMBERS SP_NI(i)%Number = SP_TEST_NUMBER(i) SP_NI(i)%Exponent = EXPONENT( SP_NI(i)%Number ) END DO
In this context, EXPONENT() always reports -1022 for the single precision case.
This looks like a compiler bug to me (the same code but using double precision variables and arguments in the intrinsics works fine). Is that a fair assessment? If so, is it a known bug? If not I can submit a bug report with my test code tarball…how is that done when one has an evaluation license?