public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "mark at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/20103] [4.0/4.1 regression] ICE in create_tmp_var with C99 style struct initializer Date: Tue, 08 Mar 2005 07:46:00 -0000 [thread overview] Message-ID: <20050308074552.3398.qmail@sourceware.org> (raw) In-Reply-To: <20050220111234.20103.falk@debian.org> ------- Additional Comments From mark at codesourcery dot com 2005-03-08 07:45 ------- Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable types Alexandre Oliva wrote: > So think of it this way: if we adopted COMPOUND_LITERAL_EXPR like > you're inclined to do, we'd have to do the very same kind of type > propagation after resolving the complete type of the initializer. > This is no different from what I'm proposing to do here. Except that (a) we'd have no change of doing it when we don't want to do it (which we do with your patch, because if the two things just happen to have the same type before substitution, we'll preserve that, even if we shouldn't, perhaps for some case/language feature/extension that hasn't even been invented yet), and (b) we'd be guaranteed to keep doing it when we do want it to happen (which we won't, with your patch, if something changes in get_target_expr). > And there's more: since there's no compiler-enforced equality AFAICT > between the type of the COMPOUND_LITERAL_EXPR and that of the VAR_DECL > enclosed in it, we'd have o make the propagation conditional in just > the same way. No, because there would be no TARGET_EXPR. In a template, you would just have a COMPOUND_LITERAL_EXPR, with no TARGET_EXPR, because we want a syntactic representation of the input program. > Note that we never needed this condition to hold before; TARGET_EXPRs > just were not handled at all: we never emitted TARGET_EXPRs whose > types were arrays of unknown bounds, to be inferred from the > initializer length, before this change. Yes, and introducing TARGET_EXPRs into templates *is a bug* because in templates we want a syntactic representation. The closest thing we have to a syntactic representation of a compound literal is a CONSTRUCTOR; it's certainly not a TARGET_EXPR wrapped around a CONSTRUCTOR. It may be just fine to use CONSTRUCTOR, instead of introducing COMPOUND_LITERAL_EXPR, but TARGET_EXPRs should not be appearing here at all. > Further investigation has shown that TARGET_EXPR's SLOTs always have > the same type as the enclosing TARGET_EXPR. Whether SLOTs and > INITIALs always have the same type is not as obvious, but it appears > to hold as well. How about making the assignments unconditional, > then, with an assertion that the equality holds? Copying the SLOT type to the EXPR type would make a lot more sense. That's along the lines of what I originally suggested: substitute into the operands, and then form the TARGET_EXPR with an appropriate type. You've just demonstrated a way to do that, in a uniform way. Unfortunately, you've also caused me to think about this long enough to realize that having the TARGET_EXPR here is wrong in the first place, as per above. > /* If the type of the initializer was used to create the original > TARGET_EXPR, make sure we adjust the type of the tsubsted > TARGET_EXPR, should the type of the initializer change in > unpredictable ways during tsubsting (e.g., the range of an array is > inferred from a CONSTRUCTOR length). */ > > See? No need to change any other piece of code anywhere else. It's > really that simple. That's not a justification; that's just a statement of what the code does. Why would we copy this type sometimes and not others? Fundamentally, what your patch says is that the semantics of TARGET_EXPR depend on whether or not the type of INITIAL matches the type of the TARGET_EXPR. If that weren't true, then we wouldn't have to check that condition before doing whatever we do. But, there's nothing about the actual semantics of TARGET_EXPR that depend on this type equality; ergo, the patch does not make sense. But, as I've said above, I think this is all moot; TARGET_EXPRs should not appear in template bodies at all. I think you've confirmed that by saying that you had to add this code. If you look at the other code that handles expressions in templates, you'll see how we preserve the syntactic form, precisely so that we can reuse the appropriate semantics.c routines at the time of instantiation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20103
next prev parent reply other threads:[~2005-03-08 7:46 UTC|newest] Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top 2005-02-20 17:37 [Bug c++/20103] New: [4.0 regression] ICE in create_tmp_var falk at debian dot org 2005-02-20 17:52 ` [Bug c++/20103] " falk at debian dot org 2005-02-20 19:02 ` pinskia at gcc dot gnu dot org 2005-02-20 19:25 ` pinskia at gcc dot gnu dot org 2005-02-20 19:27 ` pinskia at gcc dot gnu dot org 2005-02-21 21:49 ` pinskia at gcc dot gnu dot org 2005-02-23 11:10 ` [Bug c++/20103] [4.0 regression] ICE in create_tmp_var with C99 style struct initializer pinskia at gcc dot gnu dot org 2005-03-02 13:48 ` [Bug c++/20103] [4.0/4.1 " reichelt at gcc dot gnu dot org 2005-03-03 7:01 ` aoliva at gcc dot gnu dot org 2005-03-03 7:42 ` aoliva at redhat dot com 2005-03-04 23:22 ` aoliva at redhat dot com 2005-03-04 23:30 ` mark at codesourcery dot com 2005-03-05 11:41 ` giovannibajo at libero dot it 2005-03-05 12:16 ` joseph at codesourcery dot com 2005-03-05 13:37 ` aoliva at redhat dot com 2005-03-05 14:03 ` aoliva at redhat dot com 2005-03-05 21:47 ` mark at codesourcery dot com 2005-03-06 7:30 ` aoliva at redhat dot com 2005-03-06 18:02 ` mark at codesourcery dot com 2005-03-07 3:26 ` aoliva at redhat dot com 2005-03-07 4:44 ` mark at codesourcery dot com 2005-03-07 8:51 ` giovannibajo at libero dot it 2005-03-07 14:44 ` aoliva at redhat dot com 2005-03-07 16:05 ` mark at codesourcery dot com 2005-03-07 17:05 ` aoliva at redhat dot com 2005-03-07 18:05 ` mark at codesourcery dot com 2005-03-07 21:58 ` aoliva at redhat dot com 2005-03-07 22:39 ` mark at codesourcery dot com 2005-03-08 7:25 ` aoliva at redhat dot com 2005-03-08 7:46 ` mark at codesourcery dot com [this message] 2005-03-08 20:44 ` aoliva at redhat dot com 2005-03-08 21:55 ` aoliva at redhat dot com 2005-03-11 15:20 ` rth at gcc dot gnu dot org 2005-03-11 19:29 ` aoliva at redhat dot com 2005-03-17 10:42 ` aoliva at redhat dot com 2005-03-17 11:49 ` rth at gcc dot gnu dot org 2005-03-18 5:39 ` aoliva at redhat dot com 2005-03-18 10:16 ` aoliva at redhat dot com 2005-04-02 17:27 ` aoliva at redhat dot com 2005-04-05 14:47 ` pinskia at gcc dot gnu dot org 2005-04-17 3:57 ` mmitchel at gcc dot gnu dot org 2005-04-17 3:59 ` aoliva at redhat dot com 2005-04-17 4:03 ` mark at codesourcery dot com 2005-04-17 6:25 ` aoliva at redhat dot com 2005-07-06 17:03 ` mmitchel at gcc dot gnu dot org 2005-07-22 21:12 ` steven at gcc dot gnu dot org 2005-09-27 16:18 ` mmitchel at gcc dot gnu dot org [not found] <bug-20103-2744@http.gcc.gnu.org/bugzilla/> 2005-10-13 20:06 ` pinskia at gcc dot gnu dot org 2005-10-14 14:37 ` pinskia at gcc dot gnu dot org 2005-10-31 2:44 ` mmitchel at gcc dot gnu dot org 2006-05-25 20:26 ` mmitchel at gcc dot gnu dot org 2006-06-09 9:57 ` jakub at gcc dot gnu dot org 2006-06-10 22:23 ` pinskia at gcc dot gnu dot org 2006-07-03 23:52 ` tbm at cyrius dot com 2007-02-14 9:05 ` mmitchel at gcc dot gnu dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20050308074552.3398.qmail@sourceware.org \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).