From: Jason Merrill <jason@redhat.com>
To: Patrick Palka <ppalka@redhat.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] c++: abi_tag attribute on templates [PR109715]
Date: Thu, 14 Dec 2023 17:09:04 -0500 [thread overview]
Message-ID: <168ac308-cc1e-43af-8f96-19fab9dddfa8@redhat.com> (raw)
In-Reply-To: <49477513-edfe-7ab6-95d6-7ea3496707ac@idea>
On 12/14/23 16:08, Patrick Palka wrote:
> On Thu, 14 Dec 2023, Jason Merrill wrote:
>
>> On 12/14/23 14:17, Patrick Palka wrote:
>>> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
>>> trunk? Do we want to condition this on abi_check (19)?
>>
>> I think we do, sadly.
>
> Sounds good, like so? Bootstrap and regtest in progress.
>
> -- >8 --
>
> Subject: [PATCH] c++: abi_tag attribute on templates [PR109715]
>
> As with other declaration attributes, we need to look through
> TEMPLATE_DECL when looking up the abi_tag attribute.
>
> PR c++/109715
>
> gcc/cp/ChangeLog:
>
> * mangle.cc (get_abi_tags): Look through TEMPLATE_DECL.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/abi/abi-tag25.C: New test.
> * g++.dg/abi/abi-tag25a.C: New test.
> ---
> gcc/cp/mangle.cc | 6 ++++++
> gcc/testsuite/g++.dg/abi/abi-tag25.C | 17 +++++++++++++++++
> gcc/testsuite/g++.dg/abi/abi-tag25a.C | 11 +++++++++++
> 3 files changed, 34 insertions(+)
> create mode 100644 gcc/testsuite/g++.dg/abi/abi-tag25.C
> create mode 100644 gcc/testsuite/g++.dg/abi/abi-tag25a.C
>
> diff --git a/gcc/cp/mangle.cc b/gcc/cp/mangle.cc
> index 0684f0e6038..e3383df1836 100644
> --- a/gcc/cp/mangle.cc
> +++ b/gcc/cp/mangle.cc
> @@ -530,6 +530,12 @@ get_abi_tags (tree t)
> if (DECL_P (t) && DECL_DECLARES_TYPE_P (t))
> t = TREE_TYPE (t);
>
> + if (TREE_CODE (t) == TEMPLATE_DECL
> + && DECL_TEMPLATE_RESULT (t)
> + /* We used to ignore abi_tag on function and variable templates. */
> + && abi_check (19))
> + t = DECL_TEMPLATE_RESULT (t);
Generally I try to call abi_check only when we know that there's
something that will change the mangling, so here only if the template
has ABI tags. I suppose the only downside is a second mangling that
produces the same name and gets ignored in mangle_decl so we don't need
to be too strict about it, but it shouldn't be too hard to do that here?
Jason
next prev parent reply other threads:[~2023-12-14 22:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-14 19:17 Patrick Palka
2023-12-14 20:33 ` Jason Merrill
2023-12-14 21:08 ` Patrick Palka
2023-12-14 22:09 ` Jason Merrill [this message]
2023-12-15 0:59 ` Patrick Palka
2023-12-15 1:26 ` Jason Merrill
2023-12-18 8:54 ` [committed] testsuite: Fix up abi-tag25a.C test for C++11 Jakub Jelinek
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=168ac308-cc1e-43af-8f96-19fab9dddfa8@redhat.com \
--to=jason@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=ppalka@redhat.com \
/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).