public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jason Merrill <jason@redhat.com>
To: "Arsen Arsenović" <arsen@aarsen.me>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] contracts: Stop relying on mangling for naming .pre/.post clones
Date: Thu, 15 Dec 2022 16:48:36 -0500	[thread overview]
Message-ID: <1dd4376e-84c1-c81c-415e-76c41d1e2475@redhat.com> (raw)
In-Reply-To: <86bko4ttho.fsf@aarsen.me>

On 12/15/22 13:00, Arsen Arsenović wrote:
> Hi Jason,
> 
> Jason Merrill <jason@redhat.com> writes:
> 
>> On 12/10/22 08:13, Arsen Arsenović wrote:
>>> If the mangler is relied on, functions with extern "C" on them emit multiple
>>> definitions of the same name.
>>
>> But doing it here interferes with lazy mangling.  How about appending the
>> suffix into write_mangled_name instead of write_encoding?  The demangler
>> already expects "clone" suffixes at the end of the mangled name.
> 
> Ah, sorry.  I'm not well versed in the mangler code, so I didn't realize
> (frankly, I was initially surprised when I saw that DECL_ASSEMBLER_NAME
> was set that early, but went with it).  That makes sense.
> 
> How about this?  Tested on x86_64-pc-linux-gnu via check-g++.
> 
> 
> 
> I did run c++filt (afaik, it uses the libiberty demangler) on this
> revision, and I got:
> 
>            .type	f(int) [clone .pre], @function
>    f(int) [clone .pre]:
> 
> out of ``void f(int x) [[ pre: x > 10 ]] {}'', which seems to match your
> description.
> 
> If I understand this right, write_xxx corresponds to xxx in the Itanium
> ABI mangling BNF, in which case, I believe I have the correct spot here.
> In that case, a similar change should happen for coroutines; I think
> Iain was working on that.

> 	* mangle.cc (write_encoding): Move contract pre/post function mangling

It's best to wrap the ChangeLog entry at column 75 so that the extra 
indentation added by git log doesn't push past column 80.

Applied with that change.

Jason


  parent reply	other threads:[~2022-12-15 21:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-10 13:13 Arsen Arsenović
2022-12-10 13:14 ` Arsen Arsenović
2022-12-10 19:51   ` Bernhard Reutner-Fischer
2022-12-11 15:56     ` Arsen Arsenović
2022-12-15 15:40 ` Jason Merrill
2022-12-15 18:00   ` Arsen Arsenović
2022-12-15 20:29     ` Iain Sandoe
2022-12-17 11:30       ` Arsen Arsenović
2022-12-15 21:48     ` Jason Merrill [this message]
2022-12-17 11:30       ` Arsen Arsenović

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=1dd4376e-84c1-c81c-415e-76c41d1e2475@redhat.com \
    --to=jason@redhat.com \
    --cc=arsen@aarsen.me \
    --cc=gcc-patches@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: 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).