pgf95 EXPONENT intrinsic bug?

Hello,

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?

cheers,

paulv

Hi Paul,


Although we have not seen this before, it could be a new compiler bug or a problem with the code. We would need to have the full code to investigate further. I put together the code samples you posted but didn’t see the described behavior.

% cat x.f
      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 /)
      TYPE :: SP_NI_type
      REAL( Single ) :: Number
      INTEGER        :: Exponent
      END TYPE SP_NI_type
      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 )
         print *, SP_NI(i)%Number, ' ', SP_NI(i)%Exponent
      END DO
      end
% pgf90 x.f -Ktrap=ovf -fastsse -Mextend -V6.0-4
% a.out
   1.2345679E-16            -52
   0.1234568                 -3
    12.34568                  4
   1.2345678E+16             54
   9.9999998E-03             -6

Can you please send this to trs@pgroup.com? Don’t worry about the license. A bug is a bug no matter who reports it. Did this work with 5.2?

Thanks,
Mat