On Sat, Jun 16, 2018 at 09:21:16PM +0200, Janus Weil wrote: > > > Am 16. Juni 2018 18:38:40 MESZ schrieb Steve Kargl > <s...@troutmask.apl.washington.edu>: > >On Sat, Jun 16, 2018 at 01:09:36PM +0200, Janus Weil wrote: > >> > >> > >> Am 15. Juni 2018 20:38:17 MESZ schrieb Steve Kargl > ><s...@troutmask.apl.washington.edu>: > >> >> But at least for pure functions, this optimization looks Ok. > >> >> > >> > > >> >Why is everyone fixated on PURE vs IMPURE functions? > >> > >> Simply because it makes a difference in this context! > > > >It does not! A function marked as PURE by a programmer > >must meet certain requirement of the Fortran standard. > >An unmarked function or a function marked as IMPURE can > >still meet those same requirements. Marking something as > >IMPURE has only a single requirement in the standard. > > > > An impure elemental procedure processes array arguments > > in array element order. > > > >That's it. Marking a function as IMPURE does not mean > >the function has side effects. It does not mean that > >a function must be evaluated for each reference. Are > >you advocating that gfortran must evaluate ping() > >twice for > > > > impure real function ping() > > end function ping > > > > x = ping() + 0 * ping() > > end > > Absolutely, sir. That's what I'm advocating. If someone > deliberately declares a function as impure, he should be > prepared to deal with the consequences. In general, though, > one can wonder whether the compiler could not warn that > the impure declaration is not necessary (or, in other words,i > that the function would be better declared as pure).
This is a different answer than what you gave in the PR when I asked if you were special casing .and. and .or. It is trivial to force the evaluation of operands. I already posted the diff in the PR where I special cased .and. and .or. op1 .op. op2 needs to be converted to tmp1 = op1 tmp2 = op2 x = tmp1 .op. tmp for all binary operators. > In any case, the example you're showing is probably not > the most problematic one. I assume a much more frequent > and critical case would be the one where people forget > to mark a function that is effectively pure with the > PURE attribute. See Fortran 2018, Note 10.28 (if I remember correctly). That example explicitly involves .and., and it explicitly states that a function need not be evaluate. It does not sya "pure function". It says "function". -- Steve