[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@gcc.gnu.org>]

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

Alexandre Oliva wrote:
> 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.

OK, so if there's no conversion, then my suggestion (i.e., copy the type 
from the substituted initializer) should work fine.

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

TARGET_EXPRs create objects.  I'm not sure if we ever create 
TARGET_EXPRs with REFERENCE_TYPE, but if so, there initializers should 
have the same type.

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

There are two situations:

1. The type is derivable from the operands.

In that case, you can do that, as I've suggested above, by creating the 
operands, and then applying a *uniform, unconditional* operation to the 
type of the operands to determine the type of the TARGET_EXPR.

2. The type is not derivable from the operands.

In that case, you should be going through the same semantics.c routines 
that we do at parse time.

The truth is that (2) is a better choice no matter what, because we 
really want dependent expressions to have a representation that is very 
nearly isomorphic to the source code.  We have to introduce nodes 
corresponding to G++ extensions in other places (like 
statement-expressions); this is no different.  However, I can live with 
(1), for expediency sake.

>>The games that you want to play with type-equality are just too fragile.
> 
> I still don't see why.

First, you're using "==".  As I've told you, that's incredibly fragile. 
  You're depending on a very non-local property that in the case that 
you're interested in, the types will always be ==.  But, minor changes 
elsewhere might make them same_type_p, but not ==, in some cases.  Then, 
your code breaks, probably undetectably.  To a first approximation, the 
only place == should be used for types is in same_type_p itself.

Second, you're applying a non-uniform manipulation on the types of the 
TARGET_EXPR, based on a non-local property about how TARGET_EXPRs are 
created, without actually checking that the condition you're interested 
in (incomplete array types) applies.

This is not an approach that's going to be robust over time.



-- 


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