------- Comment #4 from burnus at gcc dot gnu dot org 2007-08-06 12:49 -------
Using
REAL RMACH(5)
DATA RMACH(1) / Z'00800000' /
is invalid Fortran 77/90/95/2003 as Fortran only allows:
"If a data-stmt-constant is a boz-literal-constant, the corresponding variable
shall be of type integer. The boz-literal-constant is treated as if it were an
int-literal-constant with a kind-param that specifies the representation method
with the largest decimal exponent range supported by the processor."
Gfortran interprets
DATA RMACH(1) / Z'00800000' /
as
rmach(1) = real(int(Z'00800000', maximallyNeededKind))
which is ok as the program is invalid and thus undfefined. Other compilers
interpret it as bit pattern. The result is are
8388608. respectively 1.1754944E-38.
Solution for Fortran 90/95/2003: Replace
DATA RMACH(1) / Z'00800000' /
by
RMACH(1) = transfer( Z'00800000', rmach)
I think nonetheless that gfortran misbehaves.
Expected:
- With -std=f95 etc. give a warning or an error
- With -std=gnu allow it (maybe with warning?) and tread as
transfer(Z'...', 0.0) to be compatible with the other compilers.
NAG f95 gives always the error:
Error: Data-stmt-value incompatible with data-stmt-object
whereas, e.g., g95 and ifort give a warning for -std=f95 and have the same
result as with TRANSFER.
Warning (160): BOZ constant conversion at (1) is nonstandard
Warning: Fortran 95 does not allow boz constant in this context.
--
burnus at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |burnus at gcc dot gnu dot
| |org
GCC build triplet|x86_64-redhat-linu |
GCC host triplet|x86_64-redhat-linu |
GCC target triplet|x86_64-redhat-linu |
Keywords| |diagnostic
Summary|64-bit hexadecimal DATA |Hexadecimal DATA incorrect
|incorrect |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33002
