>
> 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 <[EMAIL PROTECTED]>
> Kenneth Zadeck <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
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
