Copyright (C) 2000-2012 |
GNU Info (g77-300.info)Equivalence Versus EqualityEquivalence 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. automatically generated by info2www version 1.2.2.9 |