Hi Thomas,

>the attached patch introduces the following changes:

thanks a lot for working on this! 

>If a logical .and. or .or. expression contains a reference to a
>which is impure and which also does not behave like a pure function
>(i.e. does not have the implicit_pure attribute set), it emits a
>warning with -Wsurprising that the function might not be evaluated.
>(-Wsurprising is enabled by -Wall).

I think you are warning about too many cases here. Warning about an impure 
function as the *second* operand of the logical operators should be enough, I 
think. AFAICS there is no danger of the first operand not being evaluated, 

>It special cases the idiom  if (associated(m) .and. m%t) which
>people appear to use.

I don't fully understand why you do this, but in any case it should not be 
necessary if you warn about the second operand only.

>And, if there is an expression like   func() .and. flag , it
>reverses the test as an optimization.

I really don't like this part. It actually introduces more problems of the sort 
that we're trying to warn about ...


>2018-06-11  Thomas Koenig  <tkoe...@gcc.gnu.org>
>         PR fortran/57160
>         PR fortran/85599
>         * dump-parse-tree (show_attr): Add handling of implicit_pure.
>         * resolve.c (impure_function_callback): New function.
>         (resolve_operator): Call it vial gfc_expr_walker. Special-case
>         if (associated(m) .and. m%t).  If an .and. or .or. expression
>         has a function or a non-function, exchange the operands.
>2018-06-11  Thomas Koenig  <tkoe...@gcc.gnu.org>
>         PR fortran/57160
>         PR fortran/85599
>         * gfortran.dg/logical_evaluation_1.f90: New test.
>         * gfortran.dg/alloc_comp_default_init_2.f90: Fix code which
>         implicitly depends on short-circuiting.

Reply via email to