This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA:] Fix PR 40086 - reorg.c again and again


> From: Eric Botcazou <ebotcazou@adacore.com>
> Date: Tue, 19 May 2009 09:11:44 +0200

> > No, as safe correctness was the issue I prioritized re-using the
> > previous solution.  I thought it couldn't happen too often, or
> > this bug would have been noticed before.  What indications of
> > non-pessimization do you require?
> 
> For example looking at the impact on gcc.c-torture/compile at -O2 to get a 
> quick idea.  I've attached a patch (originally from Richard S. IIRC) that 
> preserves the assembly files generated for this directory.

Thanks, I'll do this.  I'll bring one or more bb rtl dumps too,
for clarity.

> > I'm pretty sure it's needed everywhere.  I thought I made the
> > point that PR15296 is virtually the same!  What effects would
> > the DF change have?  IIUC better live information (less live
> > registers) only aggravates the problem, it does not cause it.
> 
> Yes, but patching branches is not (usually) allowed if you don't have a 
> testcase exhibiting a regression on the branches.

Um, I'm not sure I agree to this interpretation of Rules...

I'd say that if it can be concluded that the bug is on a branch
as well and that the patch would have the intended effect, it
can be applied regardless of whether you can expose the bug with
the original test-case, at the discretion of the reviewer and
bug-fixer.  This at least to my recollection of observations.

brgds, H-P


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]