Node: Context-Sensitive Constants, Next: Equivalence Versus Equality, Previous: Context-Sensitive Intrinsicness, Up: Non-bugs
g77
does not use context to determine the types of
constants or named constants (PARAMETER
), except
for (non-standard) typeless constants such as '123'O
.
For example, consider the following statement:
PRINT *, 9.435784839284958 * 2D0
g77
will interpret the (truncated) constant
9.435784839284958
as a REAL(KIND=1)
, not REAL(KIND=2)
,
constant, because the suffix D0
is not specified.
As a result, the output of the above statement when
compiled by g77
will appear to have "less precision"
than when compiled by other compilers.
In these and other cases, some compilers detect the fact that a single-precision constant is used in a double-precision context and therefore interpret the single-precision constant as if it was explicitly specified as a double-precision constant. (This has the effect of appending decimal, not binary, zeros to the fractional part of the number--producing different computational results.)
The reason this misfeature is dangerous is that a slight, apparently innocuous change to the source code can change the computational results. Consider:
REAL ALMOST, CLOSE DOUBLE PRECISION FIVE PARAMETER (ALMOST = 5.000000000001) FIVE = 5 CLOSE = 5.000000000001 PRINT *, 5.000000000001 - FIVE PRINT *, ALMOST - FIVE PRINT *, CLOSE - FIVE END
Running the above program should
result in the same value being
printed three times.
With g77
as the compiler,
it does.
However, compiled by many other compilers,
running the above program would print
two or three distinct values, because
in two or three of the statements, the
constant 5.000000000001
, which
on most systems is exactly equal to 5.
when interpreted as a single-precision constant,
is instead interpreted as a double-precision
constant, preserving the represented
precision.
However, this "clever" promotion of
type does not extend to variables or,
in some compilers, to named constants.
Since programmers often are encouraged to replace manifest
constants or permanently-assigned variables with named
constants (PARAMETER
in Fortran), and might need
to replace some constants with variables having the same
values for pertinent portions of code,
it is important that compilers treat code so modified in the
same way so that the results of such programs are the same.
g77
helps in this regard by treating constants just
the same as variables in terms of determining their types
in a context-independent way.
Still, there is a lot of existing Fortran code that has
been written to depend on the way other compilers freely
interpret constants' types based on context, so anything
g77
can do to help flag cases of this in such code
could be very helpful.