Hi Janus, > gfortran currently does short-circuiting, and after my patch for PR > 85599 warns about cases where this might remove an impure function > call (which potentially can change results). > > Now, this PR (57160) is about code which relies on the > short-circuiting behavior. Since short-circuiting is not guaranteed by > the standard, such code is invalid. Generating a warning or an error > at compile-time is a bit harder here, though, since there are multiple > variations of such a situation, e.g.: > * ASSOCIATED(p) .AND. p%T > * ALLOCATED(a) .AND. a%T > * i<ubound(x) .AND. x(i) > * … >
Aren’t you confusing portability with validity? The above codes are indeed invalid without short-circuit evaluation, but I did not find anything in the standard saying such codes are invalid with short-circuit evaluation. > The suggestion in the PR was to do short-circuiting only with > optimization flags, but inhibit it with -O0, so that the faulty code > will run into a segfault (or runtime error) at least when > optimizations are disabled, and the problem can be identified. This PR has nothing to do with optimization and I think it is a very bad idea to (ab)use any optimization option. Please leave the default behavior (and test) as they are now. If you want non short-circuit evaluation, introduce an option for it. Note that the warning introduce for pr85599 should be disabled for non short-circuit evaluations. TIA Dominique
