public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "ndesaulniers at google dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/110728] should __attribute__((cleanup())) callback get invoked for indirect edges of asm goto
Date: Thu, 03 Aug 2023 16:00:44 +0000	[thread overview]
Message-ID: <bug-110728-4-cuF3ImnpOs@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-110728-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110728

--- Comment #10 from Nick Desaulniers <ndesaulniers at google dot com> ---
(In reply to Michael Matz from comment #9)
> That has to do with how we need to (possibly)
> split
> critical edges, which changes label identity, which in turn might actually
> be the thing that's required by the asmgoto.

(Addressing just this point for now.)

I don't think that's a problem for users of asm goto; GCC (and Clang) will
already split critical edges when using asm goto with outputs (thus creating
the case you describe where the label that the asm will jump to has been
synthesized and may differ from the final actual destination).

For example:

```c
void bar (void);

int foo (int y) {
    int x;

    if (y)
        goto end;

    asm goto ("# %1 %2":"=r"(x):"i"(&&end)::end);
    bar();
    return 0;
end:
    return x;
}
```

in the above, %1 may not equal %2.

I documented this behavior in clang
https://github.com/llvm/llvm-project/commit/329ef60f3e21fd6845e8e8b0da405cae7eb27267#diff-ec770381d76c859f5f572db789175fe44410a72608f58ad5dbb14335ba56eb97
which will be in the clang-17 release notes once clang-17 ships (currently in
-rc).

I also don't see that being a problem for the Linux kernel at the moment,
though they may need to consider that behavior.

  parent reply	other threads:[~2023-08-03 16:00 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-18 21:23 [Bug c/110728] New: " ndesaulniers at google dot com
2023-07-18 21:29 ` [Bug c/110728] " pinskia at gcc dot gnu.org
2023-07-18 21:32 ` pinskia at gcc dot gnu.org
2023-07-18 21:33 ` pinskia at gcc dot gnu.org
2023-07-18 21:48 ` pinskia at gcc dot gnu.org
2023-07-18 23:22 ` rjmccall at gmail dot com
2023-07-19  7:01 ` rguenth at gcc dot gnu.org
2023-07-19 16:46 ` [Bug middle-end/110728] " ndesaulniers at google dot com
2023-07-19 17:16 ` rjmccall at gmail dot com
2023-08-03 14:38 ` matz at gcc dot gnu.org
2023-08-03 16:00 ` ndesaulniers at google dot com [this message]
2023-08-03 16:11 ` matz at gcc dot gnu.org
2023-08-03 17:07 ` rjmccall at gmail dot com

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=bug-110728-4-cuF3ImnpOs@http.gcc.gnu.org/bugzilla/ \
    --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: 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).