public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/110079] [11/12/13/14 Regression] ICE with -freorder-blocks-and-partition and inline-asm goto
Date: Thu, 07 Mar 2024 09:08:44 +0000	[thread overview]
Message-ID: <bug-110079-4-F6c1U04LnC@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-110079-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #5 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:b209d905f5ce1fa9d76ce634fd54245ff340960b

commit r14-9355-gb209d905f5ce1fa9d76ce634fd54245ff340960b
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Mar 7 10:02:49 2024 +0100

    bb-reorder: Fix -freorder-blocks-and-partition ICEs on aarch64 with asm
goto [PR110079]

    The following testcase ICEs, because fix_crossing_unconditional_branches
    thinks that asm goto is an unconditional jump and removes it, replacing it
    with unconditional jump to one of the labels.
    This doesn't happen on x86 because the function in question isn't invoked
    there at all:
      /* If the architecture does not have unconditional branches that
         can span all of memory, convert crossing unconditional branches
         into indirect jumps.  Since adding an indirect jump also adds
         a new register usage, update the register usage information as
         well.  */
      if (!HAS_LONG_UNCOND_BRANCH)
        fix_crossing_unconditional_branches ();
    I think for the asm goto case, for the non-fallthru edge if any we should
    handle it like any other fallthru (and fix_crossing_unconditional_branches
    doesn't really deal with those, it only looks at explicit branches at the
    end of bbs and we are in cfglayout mode at that point) and for the labels
    we just pass the labels as immediates to the assembly and it is up to the
    user to figure out how to store them/branch to them or whatever they want
to
    do.
    So, the following patch fixes this by not treating asm goto as a simple
    unconditional jump.

    I really think that on the !HAS_LONG_UNCOND_BRANCH targets we have a bug
    somewhere else, where outofcfglayout or whatever should actually create
    those indirect jumps on the crossing edges instead of adding normal
    unconditional jumps, I see e.g. in
    __attribute__((cold)) int bar (char *);
    __attribute__((hot)) int baz (char *);
    void qux (int x) { if (__builtin_expect (!x, 1)) goto l1; bar (""); goto
l1; l1: baz (""); }
    void corge (int x) { if (__builtin_expect (!x, 0)) goto l1; baz (""); l2:
return; l1: bar (""); goto l2; }
    with -O2 -freorder-blocks-and-partition on aarch64 before/after this patch
    just b .L? jumps which I believe are +-32MB, so if .text is larger than
    32MB, it could fail to link, but this patch doesn't address that.

    2024-03-07  Jakub Jelinek  <jakub@redhat.com>

            PR rtl-optimization/110079
            * bb-reorder.cc (fix_crossing_unconditional_branches): Don't adjust
            asm goto.

            * gcc.dg/pr110079.c: New test.

  parent reply	other threads:[~2024-03-07  9:08 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-01 12:58 [Bug rtl-optimization/110079] New: ICE with -freorder-blocks-and-partition yancheng.li at foxmail dot com
2023-06-01 13:13 ` [Bug rtl-optimization/110079] [10/11/12/13/14 Regression] ICE with -freorder-blocks-and-partition and inline-asm goto pinskia at gcc dot gnu.org
2023-06-01 13:14 ` pinskia at gcc dot gnu.org
2023-06-02 11:48 ` yancheng.li at foxmail dot com
2023-07-07 10:45 ` [Bug rtl-optimization/110079] [11/12/13/14 " rguenth at gcc dot gnu.org
2024-01-12 14:06 ` rguenth at gcc dot gnu.org
2024-03-06 18:01 ` jakub at gcc dot gnu.org
2024-03-07  9:08 ` cvs-commit at gcc dot gnu.org [this message]
2024-03-07  9:37 ` [Bug rtl-optimization/110079] [11/12/13 " jakub at gcc dot gnu.org
2024-03-15 23:29 ` cvs-commit at gcc dot gnu.org
2024-03-18 14:41 ` [Bug rtl-optimization/110079] [11/12 " jakub at gcc dot gnu.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=bug-110079-4-F6c1U04LnC@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).