public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jason Merrill <jason@redhat.com>
To: Jakub Jelinek <jakub@redhat.com>,
	Jonathan Wakely <jwakely@redhat.com>, Jan Hubicka <jh@suse.cz>,
	gcc-patches@gcc.gnu.org, Richard Biener <rguenther@suse.de>,
	Patrick Palka <ppalka@redhat.com>
Subject: Re: [PATCH] c++, v4: Retry the aliasing of base/complete cdtor optimization at import_export_decl time [PR113208]
Date: Thu, 25 Apr 2024 11:30:48 -0400	[thread overview]
Message-ID: <32bfcf8c-1b45-444c-8729-e560952fe44b@redhat.com> (raw)
In-Reply-To: <ZipnORH5t6o2Vfka@tucnak>

On 4/25/24 07:22, Jakub Jelinek wrote:
> On Thu, Apr 25, 2024 at 02:02:32PM +0200, Jakub Jelinek wrote:
>> I've tried the following patch, but unfortunately that lead to large
>> number of regressions:
>> +FAIL: g++.dg/cpp0x/initlist25.C  -std=c++17 (test for excess errors)
> 
> So the reduced testcase for this is
> template <typename T, typename U> struct A {
>    T a1;
>    U a2;
>    template <typename V, typename W, bool = true>
>    constexpr A(V &&x, W &&y) : a1(x), a2(y) {}
> };
> template <typename> struct B;
> namespace std {
> template <class> struct initializer_list {
>    int *_M_array;
>    decltype (sizeof 0) _M_len;
> };
> }
> template <typename T, typename U> struct C {
>    void foo (std::initializer_list<A<const T, U>>);
> };
> template <class> struct D;
> template <typename T, typename = D<T>, typename = B<T>>
> struct E { E (const char *); ~E (); };
> int
> main ()
> {
>    C<E<char>, E<char>> m;
>    m.foo ({{"t", "t"}, {"y", "y"}});
> }
> Without the patch I've just posted or even with the earlier version
> of the patch the
> _ZN1AIK1EIc1DIcE1BIcEES5_EC[12]IRA2_KcSB_Lb1EEEOT_OT0_
> ctors were emitted, but with this patch they are unresolved externals.
> 
> The reason is that the code actually uses (calls) the
> _ZN1AIK1EIc1DIcE1BIcEES5_EC1IRA2_KcSB_Lb1EEEOT_OT0_
> __ct_comp constructor, that one has TREE_USED, while the
> _ZN1AIK1EIc1DIcE1BIcEES5_EC2IRA2_KcSB_Lb1EEEOT_OT0_
> __ct_base constructor is not TREE_USED.
> 
> But the c_parse_final_cleanups loop over
> FOR_EACH_VEC_SAFE_ELT (deferred_fns, i, decl)
> will ignore the TREE_USED __ct_comp because it is an alias
> and so has !DECL_SAVED_TREE:
> 5273		  if (!DECL_SAVED_TREE (decl))
> 5274		    continue;

Hmm, maybe maybe_clone_body shouldn't clear DECL_SAVED_TREE for aliases, 
but rather set it to some stub like void_node?

Though with all these changes, it's probably better to go with your 
first patch for GCC 14 and delay this approach to 15.  Your v1 patch is 
OK for 14.

Jason


  reply	other threads:[~2024-04-25 15:30 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-17  7:42 [PATCH] c++: " Jakub Jelinek
2024-04-17  9:04 ` Jan Hubicka
2024-04-17 12:32   ` Jakub Jelinek
2024-04-17 13:26     ` Jan Hubicka
2024-04-17 14:07       ` Jakub Jelinek
2024-04-17 14:34         ` Jan Hubicka
2024-04-17 14:39           ` Jakub Jelinek
2024-04-22 15:42 ` [PATCH] c++, v2: " Jakub Jelinek
2024-04-23  3:14   ` Jason Merrill
2024-04-23 16:04     ` Jakub Jelinek
2024-04-24  9:16       ` Jonathan Wakely
2024-04-24 16:16         ` [PATCH] c++, v3: " Jakub Jelinek
2024-04-24 22:39           ` Jason Merrill
2024-04-24 22:47             ` Jakub Jelinek
2024-04-25  0:43               ` Jason Merrill
2024-04-25 12:02                 ` [PATCH] c++, v4: " Jakub Jelinek
2024-04-25 14:22                   ` Jakub Jelinek
2024-04-25 15:30                     ` Jason Merrill [this message]
2024-04-25 18:42                       ` [PATCH] c++, v5: " Jakub Jelinek
2024-05-09 18:20                       ` [PATCH] c++: Optimize in maybe_clone_body aliases even when not at_eof [PR113208] Jakub Jelinek
2024-05-09 18:58                         ` Marek Polacek
2024-05-09 19:05                           ` Jakub Jelinek
2024-05-10 19:59                         ` Jason Merrill
2024-05-13 10:19                           ` Jakub Jelinek
2024-05-14 22:20                             ` Jason Merrill

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=32bfcf8c-1b45-444c-8729-e560952fe44b@redhat.com \
    --to=jason@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=jh@suse.cz \
    --cc=jwakely@redhat.com \
    --cc=ppalka@redhat.com \
    --cc=rguenther@suse.de \
    /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: link
Be 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).