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: Jan Hubicka <hubicka at ucw dot cz>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: marxin <mliska at suse dot cz>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Jan Hubicka <hubicka at ucw dot cz>, Dominique Dhumieres <dominiq at lps dot ens dot fr>, williamclodius at gmail dot com
- Date: Thu, 7 Jul 2016 16:40:35 +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>
>
> 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
overflows or underflows as signed integer.
For example it is not valid to iterate from -10 to INT_MAX with step 1.
Honza