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

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

> Alexandre Oliva wrote:
>> +    case TARGET_EXPR:
>> +      {
>> +	tree r = tsubst_copy (t, args, complain, in_decl);
>> +
>> +	TREE_TYPE (r) = RECUR (TREE_TYPE (t));
>> +	TARGET_EXPR_SLOT (r) = RECUR (TARGET_EXPR_SLOT (t));
>> +	TARGET_EXPR_INITIAL (r) = RECUR (TARGET_EXPR_INITIAL (t));
>> +	TARGET_EXPR_CLEANUP (r) = RECUR (TARGET_EXPR_CLEANUP (t));
>> +
>> +	if (TREE_TYPE (TARGET_EXPR_SLOT (t))
>> +	    == TREE_TYPE (TARGET_EXPR_INITIAL (t)))
>> +	  TREE_TYPE (TARGET_EXPR_SLOT (r)) =
>> +	    TREE_TYPE (TARGET_EXPR_INITIAL (r));
>> +
>> +	if (TREE_TYPE (t) == TREE_TYPE (TARGET_EXPR_SLOT (t)))
>> +	  TREE_TYPE (r) = TREE_TYPE (TARGET_EXPR_SLOT (r));
>> +
>> +	return r;

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

> And, the manipulations of TREE_TYPE don't make sense: (a) using "=="
> to compare types is almost always wrong,

It's right in the very case I care about, see below.

> and (b) the RECURs should already maintain the invariant you're
> trying to maintain.

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.  So what I'm doing here is propagating the completed type
to the SLOT and the TARGET_EXPR itself, otherwise their types would
remain incomplete, and errors would ensue.  This ensures that we get
the same result as that of finish_compound_literal() when not
compiling a template.



-- 


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