On Thu, Jun 28, 2018 at 07:58:22AM +0200, Janus Weil wrote: > 2018-06-27 23:47 GMT+02:00 Steve Kargl <s...@troutmask.apl.washington.edu>: > > On Wed, Jun 27, 2018 at 10:46:05PM +0200, Janus Weil wrote: > >> 2018-06-27 21:34 GMT+02:00 Thomas Koenig <tkoe...@netcologne.de>: > >> > > >> > And we are not going to change Fortran semantics. And I also oppose > >> > defining our own subset of Fortran in the hope that people will make > >> > fewer mistakes. > >> > > >> > A function is something that produces a value. If the value is not > >> > needed to produce the correct result, the function need not be called. > >> > >> That's a bit oversimplified, isn't it? > > > > 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.' 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. 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. -- Steve