This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Fortran loops
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: Dominique d'HumiÃres <dominiq at lps dot ens dot fr>, "fortran at gcc dot gnu dot org" <fortran at gcc dot gnu dot org>, williamclodius at gmail dot com, ahirst at cedint dot upm dot es, mliska at suse dot cz
- Date: Tue, 28 Jun 2016 15:49:47 +0200
- Subject: Re: Fortran loops
- Authentication-results: sourceware.org; auth=none
- References: <6662B213-476B-4624-808D-2AC0DB33E152 at lps dot ens dot fr> <20160628121011 dot GD52409 at kam dot mff dot cuni dot cz>
On Tue, Jun 28, 2016 at 2:10 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> IIRC this has already been discussed in the past (gfortran.dg/do_1.f90).
>> The Fortran standard requires that the variable i is equal to array(2)+1 on the loop exit, which causes an overflow if array(2) is equal to huge(i).
>> So the code is invalid when b(2) = huge(x), but I donât see why the overflow of the exit value should lead to an infinite loop.
>
> The reason why I ask (again as I just noticed - thanks for reminding :) is that
> the C equivalent:
>
> for(i=low;i<=high;i++)
> ... body ...
>
> is a lot easier to compile, but it will loop infinitly when the upper bound
> happens to be INT_MAX. To avoid that Fortran FE expand the loop as:
>
> if (low<high)
> {
> i=low;
> do {
> ... body ...
> if (i==high)
> break;
> i++
> }
> while (1)
> }
>
> This results in at least one extra compare and usually also extra register needed.
> If we could avoid this codegen based on fact that such loops are undefined, we would
> get improvements in thight and deeply nested loops. I.e. in exchange2 benchmark.
>
> Martin implemented the C-style codegen and it does improve code quality.
> If the fact that we produce the complex loop code above is just QOI, perhaps
> we can introduce a flag controlling this and turn into C-style loop expansion
> by default when optimizing?
> The do-3.f90 testcase tests some of those so it will need to be split into
> valid loops and invalid loops.
I guess it might be GCC on its own removing the exit test based on
undefined-overflow
and computing an upper bound on the iteration.
So if the testcases are really invalid I suppose that at least with
-Ofast the Fortran
FE could avoid the extra check. But IIRC the issue appeared on valid
loops as well.
(that said - I've been here before)
Richard.
> Honza
>
>> Dominique
>> > On Jun 27, 2016, at 6:56 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> >
>> > Hello,
>> > I have a Fortran question. The following program loops infinitly when compiled
>> > with ifort -O0, while it does the expected number of iterations with gfortran.
>> > The issue is that we do produce quite ineffective code to deal with
>> > side cases like this.
>> >
>> > is the program bellow valid and expected to terminate? If so I guess we want
>> > to have it as a testcase.
>> >
>> > Thanks,
>> > Honza
>> >
>> > program test_program
>> > integer(4) :: b(2), a(22), x
>> > integer(8) :: suma
>> >
>> > b(1) = huge(x)-10
>> > b(2) = huge(x)
>> >
>> > call test2(b, suma)
>> > print *,suma
>> >
>> > end program test_program
>> > function test2(array, s)
>> > integer(4) :: i, block(9), array(2)
>> > integer (8) :: s
>> > s = 1
>> >
>> > do i = array(1), array(2)
>> > s = s + 1
>> > end do
>> >
>> > end function test2
>> >