Use of .EQ. and .NE. on LOGICAL operands
is not supported, except via `-fugly', 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!)
Go to the first, previous, next, last section, table of contents.