This is the mail archive of the
mailing list for the GCC project.
Re: [RFA:] Fix PR 40086 - reorg.c again and again
- From: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- To: ebotcazou at adacore dot com
- Cc: hans-peter dot nilsson at axis dot com, gcc-patches at gcc dot gnu dot org
- Date: Tue, 19 May 2009 13:14:48 +0200
- Subject: Re: [RFA:] Fix PR 40086 - reorg.c again and again
> From: Eric Botcazou <firstname.lastname@example.org>
> 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,
> > 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.