This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 4.2.0 Status Report (2007-05-11)
- From: "Richard Guenther" <richard dot guenther at gmail dot com>
- To: "Jason Merrill" <jason at redhat dot com>
- Cc: "Mark Mitchell" <mark at codesourcery dot com>, "Daniel Berlin" <dberlin at dberlin dot org>, GCC <gcc at gcc dot gnu dot org>
- Date: Sun, 13 May 2007 15:29:04 +0200
- Subject: Re: GCC 4.2.0 Status Report (2007-05-11)
- References: <4644E80E.1030905@codesourcery.com> <46463FE8.2000400@redhat.com>
On 5/13/07, Jason Merrill <jason@redhat.com> wrote:
Mark Mitchell wrote:
> PR 30252: Wrong code generation, perhaps due to the C++ front end's
> representation for base classes. Jason, are you actively investigating
> this one?
I haven't been; I've been working on the forced unwind stuff, and
looking at the rvalue refs patch. If you want I can work on this first,
but I doubt that the patch would be safe enough for the release branch.
Also, has someone actually verified that this is something that would be
fixed by the bases-as-fields work?
Possibly not. See the audit trail of the PR. But, we can work around the
problem by (bootstrapped and tested on x86_64-unknown-linux-gnu):
Index: passes.c
===================================================================
--- passes.c (revision 124635)
+++ passes.c (working copy)
@@ -498,8 +498,8 @@ init_optimization_passes (void)
/* Initial scalar cleanups. */
NEXT_PASS (pass_ccp);
NEXT_PASS (pass_fre);
- NEXT_PASS (pass_dce);
NEXT_PASS (pass_forwprop);
+ NEXT_PASS (pass_dce);
NEXT_PASS (pass_copy_prop);
NEXT_PASS (pass_merge_phi);
NEXT_PASS (pass_vrp);
though the base on which I would say this patch is safe is contradicted
by the fact that it does fix (ok, work around) a regression ;) The underlying
problem looks like an alias problem or a frontend problem leading to the
alias problem, but I'm out of fu here and Sunday asks for some other things
to do.
Richard.