This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/20103] [4.0/4.1 regression] ICE in create_tmp_var with C99 style struct initializer
- From: "aoliva at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 7 Mar 2005 21:58:28 -0000
- Subject: [Bug c++/20103] [4.0/4.1 regression] ICE in create_tmp_var with C99 style struct initializer
- References: <20050220111234.20103.falk@debian.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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