This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Middle-end and optimization regressions: what should we do?
- From: Andrew Pinski <pinskia at physics dot uc dot edu>
- To: fxcoudert at gmail dot com
- Cc: fortran at gcc dot gnu dot org (fortran at gcc dot gnu dot org), gcc at gcc dot gnu dot org
- Date: Thu, 28 Jul 2005 15:47:59 -0400 (EDT)
- Subject: Re: Middle-end and optimization regressions: what should we do?
>
> Hi all,
>
> PR 22619 and PR 22509 are two examples of recent 4.1 regressions that
> showed up in gfortran, due to middle-end or optimization bugs (only
> happen at -O3). Since these are regressions, they should be treated
> before a long time passes, but since both source codes are Fortran, I
> guess people don't (and won't) want to look at them.
>
> How can we help here? Is there a way to make gfortran output a
> complete GIMPLE tree, that could be used for middle-end hackers to
> determine where the problem is? Or are we doomed to a dichotomy to
> know which patch caused these regressions?
>
> FX
>
> PS: PR 22619 appeared somewhere between 20050716 and 20050717, so
> patches that could possible have messed up are:
Patch which exposed it:
> 2005-07-16 Danny Berlin <dberlin@dberlin.org>
> Kenneth Zadeck <zadeck@naturalbridge.com>
Kenny's patch exposed the latent bug. I attached a testcase to RR
22619 showing that it is a regression from 3.2.3 and it fails in
3.3 and up. Kenny's patch changes a static variable to a static
const variable which gets "inlined".
> PR 22509 appeared between 20050713 and 20050714, so possible guilty patches are:
this was caused exposed by:
2005-07-12 Zdenek Dvorak <dvorakz@suse.cz>
PR rtl-optimization/20376
* toplev.c (process_options): Enable -fweb and -frename-registers when
unrolling.
* doc/invoke.texi: Update the information about when -fweb and
-frename-registers are enabled.
Thanks,
Andrew Pinski