Just noticed another problematic case: Calls to generic interfaces are not detected as implicitly pure, see enhanced test case in attachment. Will look into this problem on the weekend ... Cheers, Janus 2018-07-12 21:43 GMT+02:00 Janus Weil : > Hi all, > > here is a minor update of the patch, which cures some problems with > implicitly pure functions in the previous version. > > Most implicitly pure functions were actually detected correctly, but > implicitly pure functions that called other implicitly pure functions > were not detected properly, and therefore could trigger a warning. > This is fixed in the current version, which still regtests cleanly > (note that alloc-comp-3.f90 currently fails due to PR 86417). The test > case is also enhanced to include the problematic case. > > Ok for trunk? > > Cheers, > Janus > > > > 2018-07-11 23:06 GMT+02:00 Janus Weil : >> Hi all, >> >> after the dust of the heated discussion around this PR has settled a >> bit, here is another attempt to implement at least some basic warnings >> about compiler-dependent behavior concerning the short-circuiting of >> logical expressions. >> >> As a reminder (and recap of the previous discussion), the Fortran >> standard unfortunately is a bit sloppy in this area: It allows >> compilers to short-circuit the second operand of .AND. / .OR. >> operators, but does not require this. As a result, compilers can do >> what they want without conflicting with the standard, and they do: >> gfortran does short-circuiting (via TRUTH_ANDIF_EXPR/TRUTH_ORIF_EXPR), >> ifort does not. >> >> I'm continuing here the least-invasive approach of keeping gfortran's >> current behavior, but warning about cases where compilers may produce >> different results. >> >> The attached patch is very close to the version I posted previously >> (which was already approved by Janne), with the difference that the >> warnings are now triggered by -Wextra and not -Wsurprising (which is >> included in -Wall), as suggested by Nick Maclaren. I think this is >> more reasonable, since not everyone may want to see these warnings. >> >> Note that I don't want to warn about all possible optimizations that >> might be allowed by the standard, but only about those that are >> actually problematic in practice and result in compiler-dependent >> behavior. >> >> The patch regtests cleanly on x86_64-linux-gnu. Ok for trunk? >> >> Cheers, >> Janus >> >> >> 2018-07-11 Thomas Koenig >> Janus Weil >> >> 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. >> >> >> 2018-07-11 Janus Weil >> >> PR fortran/85599 >> * gfortran.dg/short_circuiting.f90: New test.