On Mon, Jun 11, 2018 at 10:22 PM, Thomas Koenig <tkoe...@netcologne.de> wrote:
> Hello world, > > the attached patch introduces the following changes: > > If a logical .and. or .or. expression contains a reference to a function > which is impure and which also does not behave like a pure function > (i.e. does not have the implicit_pure attribute set), it emits a > warning with -Wsurprising that the function might not be evaluated. > (-Wsurprising is enabled by -Wall). > > It special cases the idiom if (associated(m) .and. m%t) which > people appear to use. > > And, if there is an expression like func() .and. flag , it > reverses the test as an optimization. The middle end should be > capable of doing this, but apparently it doesn't, so the front > end might as well do this. > What about more complicated expressions like, say, "func() .and. flag .and func2() .and. flag2" etc.? Can it move all the function calls to the end? > > What it does not do is one part of PR 57160, i.e. warn against > if (a /= 0 .and. 1/a > 5) which people who are used to C might > also like to write. > > There is already quite some discussion in the PRs, especially 85599, > where not all people were of the same opinion. Let us see where the > discussion here leads us. > IMHO it's a mistake that the standard refuses to specify the evaluation strategy in the name of some rather minor hypothetical performance benefit. Either a) short-circuiting in left-to-right order or b) must evaluate all the arguments in left-to-right order My preference would be for a) as that is what most languages are doing, but even b) would be better than leaving it undefined. Also, there are AFAIU other similar weirdness with impure functions. The standard allows a compiler to optimize y = f(x) + f(x) into y = 2 * f(x) even if f is impure, which is totally bonkers. Or even not call f at all, if the compiler determines that y is not needed. -- Janne Blomqvist
