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 tree-optimization/108571] Fix for PR96373 regresses fabd_1.c with -ftrapping-math
Date: Tue, 14 Feb 2023 09:18:19 +0000	[thread overview]
Message-ID: <bug-108571-4-ytdv9vQEd7@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-108571-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #1 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Richard Sandiford <rsandifo@gcc.gnu.org>:

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

commit r13-5979-gb9c78605039f839f3c79ad8fca4f60ea9a5654ed
Author: Richard Sandiford <richard.sandiford@arm.com>
Date:   Tue Feb 14 09:18:07 2023 +0000

    vect: Make partial trapping ops use predication [PR96373]

    PR96373 points out that a predicated SVE loop currently converts
    trapping unconditional ops into unpredicated vector ops.  Doing
    the operation on inactive lanes can then raise an exception.

    As discussed in the PR trail, we aren't 100% consistent about
    whether we preserve traps or not.  But the direction of travel
    is clearly to improve that rather than live with it.  This patch
    tries to do that for the SVE case.

    Doing this regresses gcc.target/aarch64/sve/fabd_1.c.  I've added
    -fno-trapping-math for now and filed PR108571 to track it.
    A similar problem applies to fsubr_1.c.

    I think this is likely to regress Power 10, since conditional
    operations are only available for masked loops.  I think we'll
    need to add -fno-trapping-math to any affected testcases,
    but I don't have a Power 10 system to test on.

    gcc/
            PR tree-optimization/96373
            * tree-vect-stmts.cc (vectorizable_operation): Predicate trapping
            operations on the loop mask.  Reject partial vectors if this isn't
            possible.

    gcc/testsuite/
            PR tree-optimization/96373
            PR tree-optimization/108571
            * gcc.target/aarch64/sve/fabd_1.c: Add -fno-trapping-math.
            * gcc.target/aarch64/sve/fsubr_1.c: Likewise.
            * gcc.target/aarch64/sve/fmul_1.c: Expect predicate ops.
            * gcc.target/aarch64/sve/fp_arith_1.c: Likewise.

  reply	other threads:[~2023-02-14  9:18 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-27 10:42 [Bug tree-optimization/108571] New: " rsandifo at gcc dot gnu.org
2023-02-14  9:18 ` cvs-commit at gcc dot gnu.org [this message]
2023-04-03  8:58 ` [Bug tree-optimization/108571] " cvs-commit 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-108571-4-ytdv9vQEd7@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).