On Sat, Jun 16, 2018 at 10:42:16PM +0200, Janus Weil wrote: > > Am 16. Juni 2018 21:43:08 MESZ schrieb Steve Kargl > <s...@troutmask.apl.washington.edu>: > >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. > > Possibly we're having a communication issue here.
It seems so. > >> 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". > > You can stop throwing standard quotes. I do know what the > standard says about this by now. > > Point is: It does not sound very reasonable to me and I agree > with Janne that the standard's treatment of impure functions > is somewhere between careless and insane. > > If the standard says it's ok to optimize out any kind of > function, That is exactly what the Fortran standard says! I've quoted the relevant parts of Fortran standard, but you seem relucant to accept it and have ask me to stop supporting my position. For the logical expression, x = .false. .and. check() a Fortran compiler can replace this expression with x = .false. without evaluating check() (regardless of PURE vs IMPURE). That is exactly what Fortran 2018 Note 10.28 says. I won't quote it again. -- Steve
