[Bug c++/20103] [4.0/4.1 regression] ICE in create_tmp_var with C99 style struct initializer

[aoliva at redhat dot com]

------- Additional Comments From aoliva at gcc dot gnu dot org  2005-03-07 17:05 -------
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable types

On Mar  7, 2005, Mark Mitchell <mark@codesourcery.com> wrote:

> Are you sure that we can use TARGET_EXPR as a type-conversion node?

Actually, no.  I was led to believe so because there is a function
that creates a TARGET_EXPR given an initializer and a type, in
addition to the one that takes the type from the initializer.

> I would think in that case that the INITIAL for the TARGET_EXPR
> would be a call to the derived class constructor.

I was thinking references, actually, so there wouldn't be a
constructor involved.  I.e., I was trying to preserve the earlier
behavior of TARGET_EXPRs (i.e., mostly do nothing with them), while
adjusting the behavior only as much as needed for this new use.

>> We'd have to create a new tree node type for compound literals to
>> be able to call finish_compound_literal at that point.

> Then we really should do that.

Eek.  What for?  All we need to do is adjust its type.  A new tree
node scattered all over the place feels like way too much overhead for
this.

> The games that you want to play with type-equality are just too fragile.

I still don't see why.  All I am doing is ensuring the equality is
maintained if it existed.  If they weren't equal in the first place, I
just don't change anything.  As a result, in the case in which I know
the equality is important and present, it will be preserved.  In other
cases, we get the behavior we had before.

Why are you so uncomfortable with it?  Is it just the general thought
that `pointer equality between type tree nodes is bad´, before
actually looking into the problem it's trying to address, or other
reasons pertaining to this particular issue?



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20103