On Thu, Jun 28, 2018 at 05:52:43PM +0200, Janus Weil wrote: > 2018-06-28 16:41 GMT+02:00 Steve Kargl <s...@troutmask.apl.washington.edu>: > >> > Technically, the standard says an operand need not be evaluate, > >> > but you've asked people not to cite the Standard. I've also > >> > pointed you to F2018 Note 10.28 where it very clearly says that > >> > a function need not be evaluated with example nearly identical > >> > to the one in the PR. PURE vs IMPURE (or unmarked) function > >> > is a red herring. The standard makes no distinction. > >> > >> Look, Steve. This argument has been going in circles for weeks now. I > >> think we can stop it here. > >> > > > > I've already stated that I have no problem with the warning. As > > Thomas noted, gfortran should warn for both '.false. .and. check()' > > and 'check() .and. .false.' > > It doesn't really help the discussion if you just re-state other > people's positions. It might help if you would actually tell use *why* > you think both cases should be checked? > > gfortran's current implementation of .and. is intrinsically asymmetric > and only optimizes away the second operand if possible. My motivation > for the warning is mostly to signal compiler-dependent behavior, and I > still haven't seen a compiler that treats the case 'check() .and. > .false.' different from gfortran. Are you aware of one?
Why I think it a warning should be emitted: symmetry!. You complained about the lack of symmetry in 'check() .and. .false.' and '.false. .and. check()'. For the record, I also think Thomas's original patch that actually switch the operands should be applied. > > In fact, I'll be submitting a bug report for a missed optimization. > > > > subroutine foo(x,y) subroutine foo(x,y) > > real x(10), y(10) real x(10), y(10) > > y = 0*sin(x) y = 0 > > end subroutine foo end subroutine foo > > > > .L2: pxor %xmm0, %xmm0 > > call sinf movq $0, 32(%rsi) > > pxor %xmm1, %xmm1 movups %xmm0, (%rsi) > > mulss %xmm1, %xmm0 movups %xmm0, 16(%rsi) > > movss %xmm0, 0(%rbp,%rbx) > > addq $4, %rbx > > cmpq $40, %rbx > > jne .L2 > > > > which I'm sure you'll just be thrilled with. > > I can't say I'm totally thrilled with it, but, yes, I do agree it's a > missed optimization. That probably comes as a surprise to you, since > you are apparently trying to tease me in some way here (didn't work). > After all, SIN is an elemental function, thus pure and without any > side effects. The call can certainly be removed if the value is not > needed. Please submit your bug report, but please don't put me in CC. Change sin(x) to my_function_with_side_effects() if like. It is a missed optimization regardless of the function's pureness. You continue to miss my point or conveniently ignore it. You want to special case the forced evaluation of the operands in two specific logical expressions; namely, .and. and .or. If you want to force evaluation of operands, then do it for all binary operators. -- Steve
