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 middle-end/104971] [9/10 Regression] Optimisation for __builtin_ia32_readeflags corrupts the stack
Date: Tue, 10 May 2022 08:25:26 +0000	[thread overview]
Message-ID: <bug-104971-4-DdaWzWTJ6F@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-104971-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:07ab38979126c39563c2c75b8e40cb7ce9b479b3

commit r10-10697-g07ab38979126c39563c2c75b8e40cb7ce9b479b3
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sat Mar 19 13:53:12 2022 +0100

    i386: Don't emit pushf;pop for __builtin_ia32_readeflags_u* with unused lhs
[PR104971]

    __builtin_ia32_readeflags_u* aren't marked const or pure I think
    intentionally, so that they aren't CSEd from different regions of a
function
    etc. because we don't and can't easily track all dependencies between
    it and surrounding code (if somebody looks at the condition flags, it is
    dependent on the vast majority of instructions).
    But the builtin itself doesn't have any side-effects, so if we ignore the
    result of the builtin, there is no point to emit anything.

    There is a LRA bug that miscompiles the testcase which this patch makes
    latent, which is certainly worth fixing too, but IMHO this change
    (and maybe ix86_gimple_fold_builtin too which would fold it even earlier
    when it looses lhs) is worth it as well.

    2022-03-19  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/104971
            * config/i386/i386-expand.c
            (ix86_expand_builtin) <case IX86_BUILTIN_READ_FLAGS>: If ignore,
            don't push/pop anything and just return const0_rtx.

            * gcc.target/i386/pr104971.c: New test.

    (cherry picked from commit b60bc913cca7439d29a7ec9e9a7f448d8841b43c)

  parent reply	other threads:[~2022-05-10  8:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-17 18:49 [Bug middle-end/104971] New: " andrew.cooper3 at citrix dot com
2022-03-17 19:05 ` [Bug middle-end/104971] [9/10/11/12 Regression] " jakub at gcc dot gnu.org
2022-03-17 19:35 ` jakub at gcc dot gnu.org
2022-03-17 20:49 ` andrew.cooper3 at citrix dot com
2022-03-17 21:12 ` mpolacek at gcc dot gnu.org
2022-03-18 17:32 ` jakub at gcc dot gnu.org
2022-03-19 12:53 ` cvs-commit at gcc dot gnu.org
2022-03-25 16:31 ` [Bug middle-end/104971] [9/10/11 " cvs-commit at gcc dot gnu.org
2022-03-29  5:54 ` cvs-commit at gcc dot gnu.org
2022-03-30  8:17 ` [Bug middle-end/104971] [9/10 " jakub at gcc dot gnu.org
2022-05-10  8:25 ` cvs-commit at gcc dot gnu.org [this message]
2022-05-11  6:25 ` 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-104971-4-DdaWzWTJ6F@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).