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

["mark at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From mark at codesourcery dot com  2005-03-07 16:05 -------
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
 types

Alexandre Oliva wrote:

>>Then you should tsubst the INITIAL first, and unconditionally copy the
>>type to the TARGET_EXPR when you use build3.
> 
> 
> But what if the TARGET_EXPR had been created for different purposes,
> and did have a different type than that of the initializer?  Say, a
> Base& being bound to a Derived TARGET_EXPR?  That's why I'm performing
> the tests the way I am.

Are you sure that we can use TARGET_EXPR as a type-conversion node?  I 
would think in that case that the INITIAL for the TARGET_EXPR would be a 
call to the derived class constructor.  Hmm.  I suppose the type of such 
  a constructor is "void", so it may indeed be the case that there's 
really no relationship between the types.  Good point.

> Yeah, I know we'd like to do that, but we can't.  At that point we
> have no clue what that TARGET_EXPR or the CONSTRUCTOR in its initial
> came from.  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.  We could have COMPOUND_LITERAL_EXPR 
whose type would be the type in the (syntactic) cast, and whose argument 
would be the CONSTRUCTOR for the brace-enclosed initializer.  We'd 
create one of these things if the TYPE, or any of the initializers, was 
dependent.

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



-- 


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