https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85599
--- Comment #15 from Steve Kargl <sgk at troutmask dot apl.washington.edu> --- On Wed, May 09, 2018 at 10:25:59AM +0000, janus at gcc dot gnu.org wrote: > > --- Comment #14 from janus at gcc dot gnu.org --- > (In reply to Dominique d'Humieres from comment #10) > > Am I mistaken to read this as being handled by the middle-end? > > The short-circuiting is finally handled by the middle end, since the front end > translates .and. into &&. See also comment 6. > > Apparently the standard does neither require nor forbid the short-circuiting > (see c.l.f. discussion), but I would argue that it would be a more reasonable > for gfortran to avoid the short-circuiting (by translating to &), at least if > it is not clear whether the function has side effects. > To be clear. 1) Are you proposing that .AND. should be special-cased to force evaluation of both operands? 2) Are you proposing that the operands in rational expressions must be evaluated? 3) Are you proposing that the operands for all operators must be evaluated? If the answer to any of the above is 'yes', then add a new option -fno-short-circuit and implement it to transform result = op1 binop op2 into tmp1 = op1 tmp2 = op2 result = tmp1 BINOP tmp2 where BINOP differs from binop in that it knows tmp1 and tmp2 have been evaluated. To be completely symmetric, you'll need a similar treatment for unary operators. That is result = unop op1 becomes tmp1 = op1 result = UNOP tmp1 The flow of the compiler would then be parse code if (no short circuit) then walk expression trees forcing evaulation of all operands else front optimize pass (walk expression trees) end if Give everything to middle-end Seems like a good method to pessimize performance.
