https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85599
--- Comment #16 from janus at gcc dot gnu.org --- (In reply to Steve Kargl from comment #15) > To be clear. First of all, I'd have preferred to have a Fortran standard which gives clear and precise instructions on how a compiler should handle cases like the one that I brought up. However this does not seem to be the case: A compiler is apparently allowed (but not required) to do short-circuiting. > 1) Are you proposing that .AND. should be special-cased to > force evaluation of both operands? I'm not quite sure what you mean by "special casing", but I don't think I want to do that. > 2) Are you proposing that the operands in rational expressions > must be evaluated? Basically yes. I think gfortran should be more 'conservative' about this optimization: Either not do short-circuiting at all, or only do it if one can prove that there are no side effects that can change results (i.e. the case of PURE functions). > 3) Are you proposing that the operands for all operators must > be evaluated? The argument above is not specific to logical operators: An operation should only be optimized away if it can not change any measurable result. > If the answer to any of the above is 'yes', then add a new > option -fno-short-circuit I'm not too keen on adding a new option. Short-circuiting is not guaranteed by the standard, so people should not rely on it anyway (also other compilers don't do it). Performance might slightly decrease in some cases, but I'd hope it's not that bad (the PURE attribute can help). I'd prioritize correctness over performance. > and implement it to transform > result = op1 binop op2 > > into > > tmp1 = op1 > tmp2 = op2 > result = tmp1 BINOP tmp2 That's not what I had in mind. I'd rather make a change from result = op1 && op2 to result = op1 & op1 (cf. comment #6).
