------- 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 <[EMAIL PROTECTED]> 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
