On Wed, Jun 27, 2018 at 11:09:56AM +0300, Janne Blomqvist wrote:
> 
> How about committing a patch changing to use TRUTH_{AND|OR}_EXPR, and then
> check benchmark results (polyhedron, spec etc.)? If performance worsens, we
> revert, if it improves, great, lets keep it?
> 
> To clarify, I'm not objecting to using TRUTH_{AND|OR}_EXPR, I'm objecting
> to the notion that this is somehow "more correct" or "less bad" than the
> current short-circuiting. The Fortran standard does not specify an
> evaluation strategy; IMHO very unfortunately, but it is what it is.
> 

Benchmarks aren't going to prove anything unless the 
benchmarks have the specific construct under discuss.
Here's my benchmark that uses '.false. .and. check()'
construct.  Note, check() has no side-effect.

% cat b.f90
program b
  logical, external :: check
  if (.false. .and. check()) then
     print *, 'here'
  else
     print *, 'there'
  end if
end program b
% cat a.f90
logical function check()
   real x
10 call random_number(x)
   if (x < 2) goto 10
   check = .false.
end function check
% gfortran -o z a.f90 b.f90 && ./z
 there

-- 
Steve

Reply via email to