This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Patch: heisenbug in PRE
- From: Jeffrey A Law <law at redhat dot com>
- To: Daniel Berlin <dberlin at dberlin dot org>
- Cc: Dale Johannesen <dalej at apple dot com>, "gcc-patches at gcc dot gnu dot org Patches" <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 21 Mar 2005 12:28:46 -0700
- Subject: Re: Patch: heisenbug in PRE
- Organization: Red Hat, Inc
- References: <305e7133c60e1657c9fd0355a6991345@apple.com> <1111432443.5919.2.camel@linux.site>
- Reply-to: law at redhat dot com
On Mon, 2005-03-21 at 14:14 -0500, Daniel Berlin wrote:
> On Mon, 2005-03-21 at 10:56 -0800, Dale Johannesen wrote:
> > Ping.
> > http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01810.html
> > This is obviously correct, but I wanted to give people a chance to
> > object to
> > referencing SSA_NAME in the C++ parts, which is not done anywhere
> > else. I'll commit if nobody speaks up.
> >
>
> I'm personally curious why the SSA_NAME shows up in a type in the first
> place (it means this type is only valid in basic blocks dominated by the
> definition of this name, which seems a bit weird) , but i doubt there is
> anything you can do about it.
I think it was the upper bound on an array. However, I'm also somewhat
surprised that we have an SSA_NAME rather than a _DECL node.
Even if there's nothing we can do about having an SSA_NAME in the
type, I really wonder if we want to start down the road of front-ends
having to know anything about SSA_NAMEs. The alternative is to
avoid passing down objects with embedded SSA_NAMEs to the various
front-end hooks, which could get awful ugly.
jeff