[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 14:44 -------
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable types

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

> Alexandre Oliva wrote:
>>> This doesn't look quite right.  First, we're trying to get rid of
>>> tsubst_copy; we should not add new calls.  You should do the RECURs
>>> here, and then build up the new node.
>> I'd have to use build3 (TARGET_EXPR...) or introduce a new call to
>> create a target_expr with given slot, initial and cleanup, because
>> AFAICT there isn't any that takes a cleanup.

> Yes, you should use build3.

Ok.

>> They don't, and they can't without this piece of code.  When we tsubst
>> INITIAL, an incomplete array type (T[]), that had been used as the
>> type of the slot and the target_expr itself in
>> finish_compound_literal(), called while processing a template,
>> digest_init() (or something else; I no longer remember exactly)
>> completes the array type with the number of entries in the INITIAL
>> CONSTRUCTOR.

> 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.

> Or, even better, call
> the same functions in semantics.c that the parser would call if not in
> a template.  In other words, call finish_compound_literal again, from
> pt.c.  That's the overall design: we try to reuse the same semantic
> routines again at template instantiation time.

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.



-- 


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