This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


------- Additional Comments From aoliva at gcc dot gnu dot org  2005-03-07 21:58 -------
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable types

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

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

Not for the purpose I've been trying to describe.

The condition I want to maintain is that, if the TARGET_EXPR had the
type of its INITIAL before template substitution, then it must have
the type of its INITIAL after template substitution, because whatever
transformations the INITIAL type might undergo won't be applied to the
TARGET_EXPR.  It's that simple, so it should be quite obvious that
`==' is what I'm looking for.  It's not just same_type_p; if the types
of the TARGET_EXPR was not taken from the INITIAL, then I don't care
how it evolves.

> You're depending on a very non-local property that in the
> case that you're interested in, the types will always be ==.

No, I'm only guaranteeing that, if this property held before template
substitution, it still holds afterwards.  If it didn't hold before, it
still won't hold afterwards.  It's much simpler than what you
describe.

> But, minor changes elsewhere might make them same_type_p, but not
> ==, in some cases.

If that's fine for those cases, it will remain so after template
substitution.  Sounds *exactly* like what I want.

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

Huh?!?  No, I'm not.  Read the code again.  It goes like this:

  if the decl type and the initializer type were the same before,
    make them the same after

  if the target_expr type and the decl type were the same before,
    make them the same after

and that's it.  It's that simple.  Nothing non-uniform about it.



-- 


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]