This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 0/2, fortran] Better code generation for DO loops with +-1 step
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Martin Liška <mliska at suse dot cz>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, Richard Biener <richard dot guenther at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Dominique Dhumieres <dominiq at lps dot ens dot fr>, williamclodius at gmail dot com
- Date: Fri, 8 Jul 2016 10:40:29 +0200
- Subject: Re: [PATCH 0/2, fortran] Better code generation for DO loops with +-1 step
- Authentication-results: sourceware.org; auth=none
- References: <cover.1467883947.git.mliska@suse.cz> <CAFiYyc0FM93FwqjYOB+V2yn8b=g5xFL09U2xT0gaCOZLc4z3tA@mail.gmail.com> <20160707144035.GA30837@kam.mff.cuni.cz> <c1dd7016-53bc-0ff9-cb26-36054bfdbaaa@suse.cz>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Fri, Jul 08, 2016 at 10:33:45AM +0200, Martin Liška wrote:
> On 07/07/2016 04:40 PM, Jan Hubicka wrote:
> >>
> >> Why is the behavior only undefined for step 1 if the last iteration IV
> >> increment overflows?
> >> Doesn't this apply to all step values?
> >
> > This is what Fortran standard says:
> >
> > The iteration count is established and is the value of the expression (m2-m1+m3)/m3 unless that value is negative,
> > in which case the iteration count is 0.
> >
> > My reading of this is that the do statement is undefined whenever the expression above is undefined
> > (m1 is lower bound, m2 is upper bound, m3 is step) and because I think the evaulation order of
> > m2-m1+m3 is not fixed, I think the statement is not defined whethever (m2-m1), (m1+m3) or (m2-m1)+m3
m1+m3? Did you mean m3-m1 or -m1+m3 instead?
Jakub