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/105951] [12/13 Regression] ICE in emit_store_flag, at expmed.cc:6027
Date: Thu, 16 Jun 2022 09:01:08 +0000	[thread overview]
Message-ID: <bug-105951-4-tGudU3ELYH@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-105951-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #4 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:6a27c430468cb85454b19cef881a1422580657ff

commit r13-1132-g6a27c430468cb85454b19cef881a1422580657ff
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Jun 16 10:58:58 2022 +0200

    expand: Fix up IFN_ATOMIC_{BIT*,*CMP_0} expansion [PR105951]

    Both IFN_ATOMIC_BIT_TEST_AND_* and IFN_ATOMIC_*_FETCH_CMP_0 ifns
    are matched if their corresponding optab is implemented for the particular
    mode.  The fact that those optabs are implemented doesn't guarantee
    they will succeed though, they can just FAIL in their expansion.
    The expansion in that case uses expand_atomic_fetch_op as fallback, but
    as has been reported and and can be reproduced on the testcases,
    even those can fail and we didn't have any fallback after that.
    For IFN_ATOMIC_BIT_TEST_AND_* we actually have such calls.  One is
    done whenever we lost lhs of the ifn at some point in between matching
    it in tree-ssa-ccp.cc and expansion.  The following patch for that case
    just falls through and expands as if there was a lhs, creates a temporary
    for it.  For the other expand_atomic_fetch_op call in the same expander
    and for the only expand_atomic_fetch_op call in the other, this falls
    back the hard way, by constructing a CALL_EXPR to the call from which
    the ifn has been matched and expanding that.  Either it is lucky and
manages
    to expand inline, or it emits a libatomic API call.
    So that we don't have to rediscover which builtin function to call in the
    fallback, we record at tree-ssa-ccp.cc time gimple_call_fn (call) in
    an extra argument to the ifn.

    2022-06-16  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/105951
            * tree-ssa-ccp.cc (optimize_atomic_bit_test_and,
            optimize_atomic_op_fetch_cmp_0): Remember gimple_call_fn (call)
            as last argument to the internal functions.
            * builtins.cc (expand_ifn_atomic_bit_test_and): Adjust for the
            extra call argument to ifns.  If expand_atomic_fetch_op fails for
the
            lhs == NULL_TREE case, fall through into the optab code with
            gen_reg_rtx (mode) as target.  If second expand_atomic_fetch_op
            fails, construct a CALL_EXPR and expand that.
            (expand_ifn_atomic_op_fetch_cmp_0): Adjust for the extra call
argument
            to ifns.  If expand_atomic_fetch_op fails, construct a CALL_EXPR
and
            expand that.

            * gcc.target/i386/pr105951-1.c: New test.
            * gcc.target/i386/pr105951-2.c: New test.

  parent reply	other threads:[~2022-06-16  9:01 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-13 17:44 [Bug c/105951] New: " gscfq@t-online.de
2022-06-14  6:22 ` [Bug target/105951] " ubizjak at gmail dot com
2022-06-14  6:24 ` ubizjak at gmail dot com
2022-06-14  8:18 ` [Bug middle-end/105951] " rguenth at gcc dot gnu.org
2022-06-14 17:10 ` jakub at gcc dot gnu.org
2022-06-16  9:01 ` cvs-commit at gcc dot gnu.org [this message]
2022-06-16  9:37 ` [Bug middle-end/105951] [12 " jakub at gcc dot gnu.org
2022-06-19 10:08 ` cvs-commit at gcc dot gnu.org
2022-06-20  9:57 ` 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-105951-4-tGudU3ELYH@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).