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: dominiq at lps dot ens dot fr (Dominique Dhumieres)
- To: gcc at gcc dot gnu dot org
- Cc: hubicka at ucw dot cz, fortran at gcc dot gnu dot org
- Date: Thu, 06 Sep 2007 08:11:37 +0200
- Subject: Re: Someone has caused regressions in gfortran
> 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.
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