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 target/109254] Bug in gcc (13.0.1) support for ARM SVE, which randomly modifies the prediction register
Date: Sat, 01 Apr 2023 06:58:57 +0000	[thread overview]
Message-ID: <bug-109254-4-qgJB0NDfMu@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-109254-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #7 from CVS 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:b1f6cb2cc3aad0521ad3181d5107e52be155fd18

commit r13-6965-gb1f6cb2cc3aad0521ad3181d5107e52be155fd18
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sat Apr 1 08:55:55 2023 +0200

    aarch64, builtins: Include PR registers in FUNCTION_ARG_REGNO_P etc.
[PR109254]

    The following testcase is miscompiled on aarch64-linux in the regname pass,
    because while the function takes arguments in the p0 register,
    FUNCTION_ARG_REGNO_P doesn't reflect that, so DF doesn't know the register
is
    used in register passing. It sees 2 chains with p1 register and wants to
    replace the second one and as DF doesn't know p0 is live at the start of
the
    function, it will happily use p0 register even when it is used in
subsequent
    instructions.

    The following patch fixes that.  FUNCTION_ARG_REGNO_P returns non-zero
    for p0-p3 (unconditionally, seems for the floating/vector registers it
    doesn't conditionalize them on TARGET_FLOAT either, but if you want,
    I can conditionalize p0-p3 on TARGET_SVE), similarly
    targetm.calls.function_value_regno_p returns true for p0-p3 registers
    if TARGET_SVE (again for consistency, that function conditionalizes
    the float/vector on TARGET_FLOAT).

    Now, that change broke bootstrap in libobjc and some
    __builtin_apply_args/__builtin_apply/__builtin_return tests.  The
    aarch64_get_reg_raw_mode hook already documents that SVE scalable
arg/return
    passing is fundamentally incompatible with those builtins, but unlike
    the floating/vector regs where it forces a fixed vector mode, I think
    there is no fixed mode which could be used for p0-p3.  So, I have tweaked
    the generic code so that it uses VOIDmode return from that hook to signal
    that a register shouldn't be touched by
    __builtin_apply_args/__builtin_apply/__builtin_return
    despite being mentioned in FUNCTION_ARG_REGNO_P or
    targetm.calls.function_value_regno_p.

    gcc/
    2023-04-01  Jakub Jelinek  <jakub@redhat.com>

            PR target/109254
            * builtins.cc (apply_args_size): If targetm.calls.get_raw_arg_mode
            returns VOIDmode, handle it like if the register isn't used for
            passing arguments at all.
            (apply_result_size): If targetm.calls.get_raw_result_mode returns
            VOIDmode, handle it like if the register isn't used for returning
            results at all.
            * target.def (get_raw_result_mode, get_raw_arg_mode): Document what
it
            means to return VOIDmode.
            * doc/tm.texi: Regenerated.
            * config/aarch64/aarch64.cc (aarch64_function_value_regno_p):
Return
            TARGET_SVE for P0_REGNUM.
            (aarch64_function_arg_regno_p): Also return true for p0-p3.
            (aarch64_get_reg_raw_mode): Return VOIDmode for PR_REGNUM_P regs.

    gcc/testsuite/
    2023-04-01  Jakub Jelinek  <jakub@redhat.com>
                Richard Sandiford  <richard.sandiford@arm.com>

            PR target/109254
            * gcc.target/aarch64/sve/pr109254.c: New test.

  parent reply	other threads:[~2023-04-01  6:58 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-23  3:14 [Bug target/109254] New: " wumingchuan1992 at foxmail dot com
2023-03-23  3:23 ` [Bug target/109254] " pinskia at gcc dot gnu.org
2023-03-23 14:43 ` jakub at gcc dot gnu.org
2023-03-23 16:08 ` jakub at gcc dot gnu.org
2023-03-23 17:13 ` jakub at gcc dot gnu.org
2023-03-24 12:24 ` jakub at gcc dot gnu.org
2023-03-27  7:53 ` pinskia at gcc dot gnu.org
2023-04-01  6:58 ` cvs-commit at gcc dot gnu.org [this message]
2023-04-03 13:18 ` jakub at gcc dot gnu.org
2024-02-28  6:48 ` pinskia 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-109254-4-qgJB0NDfMu@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).