public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc r13-8387] simplify-rtx: Fix up last argument to simplify_gen_unary [PR113656] Date: Sat, 2 Mar 2024 00:38:36 +0000 (GMT) [thread overview] Message-ID: <20240302003836.F15DF3858427@sourceware.org> (raw) https://gcc.gnu.org/g:21d7bffdbe2046cc787fa31a5df5c71dc645b304 commit r13-8387-g21d7bffdbe2046cc787fa31a5df5c71dc645b304 Author: Jakub Jelinek <jakub@redhat.com> Date: Wed Jan 31 10:56:56 2024 +0100 simplify-rtx: Fix up last argument to simplify_gen_unary [PR113656] When simplifying e.g. (float_truncate:SF (float_truncate:DF (reg:XF)) or (float_truncate:SF (float_extend:XF (reg:DF)) etc. into (float_truncate:SF (reg:XF)) or (float_truncate:SF (reg:DF)) we call simplify_gen_unary with incorrect op_mode argument, it should be the argument's mode, but we call it with the outer mode instead. As these are all floating point operations, the argument always has non-VOIDmode and so we can just use that mode (as done in similar simplifications a few lines later), but neither FLOAT_TRUNCATE nor FLOAT_EXTEND are operations that should have the same modes of operand and result. This bug hasn't been a problem for years because normally op_mode is used only if the mode of op is VOIDmode, otherwise it is redundant, but r10-2139 added an assertion in some spots that op_mode is right even in such cases. 2024-01-31 Jakub Jelinek <jakub@redhat.com> PR rtl-optimization/113656 * simplify-rtx.cc (simplify_context::simplify_unary_operation_1) <case FLOAT_TRUNCATE>: Fix up last argument to simplify_gen_unary. * gcc.target/i386/pr113656.c: New test. (cherry picked from commit b59775b642bb2b1ecd2e6d52c988b9c432117bc8) Diff: --- gcc/simplify-rtx.cc | 2 +- gcc/testsuite/gcc.target/i386/pr113656.c | 12 ++++++++++++ 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/gcc/simplify-rtx.cc b/gcc/simplify-rtx.cc index ee75079917f..33fa88d369d 100644 --- a/gcc/simplify-rtx.cc +++ b/gcc/simplify-rtx.cc @@ -1305,7 +1305,7 @@ simplify_context::simplify_unary_operation_1 (rtx_code code, machine_mode mode, > GET_MODE_UNIT_SIZE (mode) ? FLOAT_TRUNCATE : FLOAT_EXTEND, mode, - XEXP (op, 0), mode); + XEXP (op, 0), GET_MODE (XEXP (op, 0))); /* (float_truncate (float x)) is (float x) */ if ((GET_CODE (op) == FLOAT || GET_CODE (op) == UNSIGNED_FLOAT) diff --git a/gcc/testsuite/gcc.target/i386/pr113656.c b/gcc/testsuite/gcc.target/i386/pr113656.c new file mode 100644 index 00000000000..fa57a56bfc8 --- /dev/null +++ b/gcc/testsuite/gcc.target/i386/pr113656.c @@ -0,0 +1,12 @@ +/* PR rtl-optimization/113656 */ +/* { dg-do compile } */ +/* { dg-options "-O3 -frounding-math -funsafe-math-optimizations -mavx512fp16 -mavx512vl" } */ + +_Float16 a[8]; + +void +foo () +{ + for (int i = 0; i < 8; i++) + a[i] = i - 8.4; +}
reply other threads:[~2024-03-02 0:38 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20240302003836.F15DF3858427@sourceware.org \ --to=jakub@gcc.gnu.org \ --cc=gcc-cvs@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: linkBe 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).