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: Steve Kargl <sgk at troutmask dot apl dot washington dot edu>
- To: Fran?ois-Xavier Coudert <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 10:41:48 -0700
- Subject: Re: Middle-end and optimization regressions: what should we do?
- References: <19c433eb0507281026355950aa@mail.gmail.com>
On Thu, Jul 28, 2005 at 07:26:22PM +0200, Fran?ois-Xavier Coudert wrote:
>
> 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?
>
These types of regressions have essentially halted my testing
and development on gfortran because I usually try to identify
the exact ChangeLog entry associated with the problem. This
typically involves a binary search for the problem with a
bootstrap in a clean directory for each "cvs update -D <date>".
As far as providing info to the middle-end people, you can
do -fdump-tree-all and try to sift through the volumes of
data.
--
Steve