This is the mail archive of the
mailing list for the GCC project.
Re: [Patch, Fortran] PR 57160: short-circuit IF only with -ffrontend-optimize
- From: Dominique d'Humières <dominiq at lps dot ens dot fr>
- To: Janus Weil <janus at gcc dot gnu dot org>
- Cc: adam at aphirst dot karoo dot co dot uk, gfortran <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 24 Jul 2018 11:12:04 +0200
- Subject: Re: [Patch, Fortran] PR 57160: short-circuit IF only with -ffrontend-optimize
> 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.