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 >function >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, right? >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 ... Cheers, Janus >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.
