2018-06-28 18:22 GMT+02:00 Steve Kargl <s...@troutmask.apl.washington.edu>: > 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()'.
well, my original complaint in PR85599 was that the second one is broken, and your reaction to that is to break the first one as well. >> > 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. Yes, if you're an orthodox believer in The One True Standard. I'd rather use my own brain cells now and then. In this case my brain just tells me that it's not a good idea to apply an optimization that can totally change the results of my code, and that it's not a good idea for a 'standard' to not define the semantics of an operator / expression, but instead leave it to the compiler how it should be evaluated. You insist that the standard does not forbid this optimization. The standard also does not forbid explicitly that you shoot yourself it the foot with a nuclear missile. So, you go ahead and shoot. Then someone comes along and asks why you did that, and you reply: "The standard did not forbid it." One thing that I always failed to comprehend is people's fixation on optimization. What's so great about your code running 0.1% faster if the second compiler you try gives you totally different results, with no hints whether it's your code that's broken, or the first compiler, or the second one, or the standard that both compilers tried to implement? With a ten-line code that might not be such a big problem, but above 100.000 loc or so it can quickly become a huge issue. Cheers, Janus
