https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85599
--- Comment #4 from janus at gcc dot gnu.org --- (In reply to kargl from comment #1) > The behavior may not be buggy, and it's best not to depend > on side-effects. From F2018, > > 10.1.5.4.2 Evaluation of logical intrinsic operations > > Once the interpretation of a logical intrinsic operation is > established, the processor may evaluate any other expression > that is logically equivalent, provided that the integrity of > parentheses in any expression is not violated. > > Two expressions of type logical are logically equivalent > if their values are equal for all possible values of their > primaries. > Thanks for the standard quote, Steve. It certainly goes in the right direction, but I feel like it's not quite to the point. Some other (possibly) relevant passages I found in the 2008 standard: ***** 7.1.7 Evaluation of operands 1 It is not necessary for a processor to evaluate all of the operands of an expression, or to evaluate entirely each operand, if the value of the expression can be determined otherwise. ***** That also sounds like optimizing away the function call might be valid, but then there is also this one: ***** 7.1.4 Evaluation of operations 2 The evaluation of a function reference shall neither affect nor be affected by the evaluation of any other entity within the statement. ***** The way I read it, gfortran's implementation currently violates this clause for the expression "flag = flag .and. check()", because the evaluation of the function reference "check()" is affected by the value of the variable "flag". So I'd argue that the bug here is not missed-optimization in the first case, but over-optimization in the second, after all. What worries me most is that other compilers choose different implementations. Can this kind of code really be processor-dependent?
