Middle-end and optimization regressions: what should we do?

[Andrew Pinski]

> 
> 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