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? > I am opposed to the change of TRUTH_AND_EXPR to TRUTH_ANDIF_EXPR, > where you are special casing logical expressions that involve > .and. and .or. It's the other way around. We currently have TRUTH_ANDIF_EXPR. And no one really wants to change it right now. Let's move on. > 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. Thanks, Janus