Info Node: (g77-300.info)Equivalence Versus Equality
(g77-300.info)Equivalence Versus Equality
Equivalence Versus Equality
---------------------------
Use of `.EQ.' and `.NE.' on `LOGICAL' operands is not supported,
except via `-fugly-logint', which is not recommended except for legacy
code (where the behavior expected by the _code_ is assumed).
Legacy code should be changed, as resources permit, to use `.EQV.'
and `.NEQV.' instead, as these are permitted by the various Fortran
standards.
New code should never be written expecting `.EQ.' or `.NE.' to work
if either of its operands is `LOGICAL'.
The problem with supporting this "feature" is that there is unlikely
to be consensus on how it works, as illustrated by the following sample
program:
LOGICAL L,M,N
DATA L,M,N /3*.FALSE./
IF (L.AND.M.EQ.N) PRINT *,'L.AND.M.EQ.N'
END
The issue raised by the above sample program is: what is the
precedence of `.EQ.' (and `.NE.') when applied to `LOGICAL' operands?
Some programmers will argue that it is the same as the precedence
for `.EQ.' when applied to numeric (such as `INTEGER') operands. By
this interpretation, the subexpression `M.EQ.N' must be evaluated first
in the above program, resulting in a program that, when run, does not
execute the `PRINT' statement.
Other programmers will argue that the precedence is the same as the
precedence for `.EQV.', which is restricted by the standards to
`LOGICAL' operands. By this interpretation, the subexpression
`L.AND.M' must be evaluated first, resulting in a program that _does_
execute the `PRINT' statement.
Assigning arbitrary semantic interpretations to syntactic expressions
that might legitimately have more than one "obvious" interpretation is
generally unwise.
The creators of the various Fortran standards have done a good job
in this case, requiring a distinct set of operators (which have their
own distinct precedence) to compare `LOGICAL' operands. This
requirement results in expression syntax with more certain precedence
(without requiring substantial context), making it easier for
programmers to read existing code. `g77' will avoid muddying up
elements of the Fortran language that were well-designed in the first
place.
(Ask C programmers about the precedence of expressions such as `(a)
& (b)' and `(a) - (b)'--they cannot even tell you, without knowing more
context, whether the `&' and `-' operators are infix (binary) or unary!)
Most dangerous of all is the fact that, even assuming consensus on
its meaning, an expression like `L.AND.M.EQ.N', if it is the result of
a typographical error, doesn't _look_ like it has such a typo. Even
experienced Fortran programmers would not likely notice that
`L.AND.M.EQV.N' was, in fact, intended.
So, this is a prime example of a circumstance in which a quality
compiler diagnoses the code, instead of leaving it up to someone
debugging it to know to turn on special compiler options that might
diagnose it.