This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Someone has caused regressions in gfortran
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Dominique Dhumieres <dominiq at lps dot ens dot fr>
- Cc: gcc at gcc dot gnu dot org, hubicka at ucw dot cz, fortran at gcc dot gnu dot org
- Date: Thu, 6 Sep 2007 09:40:40 +0200
- Subject: Re: Someone has caused regressions in gfortran
- References: <20070906061137.397255BB46@mailhost.lps.ens.fr>
> > Sadly, the testsuite regressions don't seems to be fixed. I will try to
> > figure out tomorrow why the function is still being inlined.
>
> The test case gfortran.dg/do_3.F90 pass with -fno-strict-overflow
> (see http://gcc.gnu.org/ml/fortran/2007-09/msg00116.html).
> I have posted at http://gcc.gnu.org/ml/fortran/2007-09/msg00107.html
> a reduced test case without inlining issues showing a similar
> breakage. If someone can show that before the recent failure
> the functions were not inlined, I think the failure would
> be fully explained. Otherwise it will require further investigation.
The testcase was indeed previously not inlined at all. Shall we add
-fno-strict-overflow to the testcase then?
Honza
>
> As far as I can tell without -fno-strict-overflow the executable
> reduces to a call abort at the level of
>
> if (i /= final) call abort
>
> as if final = huge(to)+1_1 giving an overflow, the comparison is
> assuming to always fail. I remember a lot of traffic on the gcc mailing
> list a couple months ago about this kind of optimization and the
> reasons behind -fno-strict-overflow, but I dont have the time right
> now to look deeper.
>
> Dominique