Node: Context-Sensitive Constants, Next: , Previous: Context-Sensitive Intrinsicness, Up: Non-bugs

Context-Sensitive Constants

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:

     PARAMETER (ALMOST = 5.000000000001)
     FIVE = 5
     CLOSE = 5.000000000001
     PRINT *, 5.000000000001 - FIVE

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.