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/114184] [12/13 Regression] ICE: in extract_insn, at recog.cc:2812 (unrecognizable insn ) with _Complex long double and vector VCE
Date: Fri, 15 Mar 2024 23:29:10 +0000	[thread overview]
Message-ID: <bug-114184-4-BTeefwEg1c@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-114184-4@http.gcc.gnu.org/bugzilla/>

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

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

https://gcc.gnu.org/g:128860abd58605d616c184a9a68886a25862b2dd

commit r13-8446-g128860abd58605d616c184a9a68886a25862b2dd
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Mon Mar 4 10:04:19 2024 +0100

    i386: Fix ICEs with SUBREGs from vector etc. constants to XFmode [PR114184]

    The Intel extended format has the various weird number categories,
    pseudo denormals, pseudo infinities, pseudo NaNs and unnormals.
    Those are not representable in the GCC real_value and so neither
    GIMPLE nor RTX VIEW_CONVERT_EXPR/SUBREG folding folds those into
    constants.

    As can be seen on the following testcase, because it isn't folded
    (since GCC 12, before that we were folding it) we can end up with
    a SUBREG of a CONST_VECTOR or similar constant, which isn't valid
    general_operand, so we ICE during vregs pass trying to recognize
    the move instruction.
    Initially I thought it is a middle-end bug, the movxf instruction
    has general_operand predicate, but the middle-end certainly never
    tests that predicate, seems moves are special optabs.
    And looking at other mov optabs, e.g. for vector modes the i386
    patterns use nonimmediate_operand predicate on the input, yet
    ix86_expand_vector_move deals with CONSTANT_P and SUBREG of CONSTANT_P
    arguments which if the predicate was checked couldn't ever make it through.

    The following patch handles this case similarly to the
    ix86_expand_vector_move's SUBREG of CONSTANT_P case, does it just for
XFmode
    because I believe that is the only mode that needs it from the scalar ones,
    others should just be folded.

    2024-03-04  Jakub Jelinek  <jakub@redhat.com>

            PR target/114184
            * config/i386/i386-expand.cc (ix86_expand_move): If XFmode op1
            is SUBREG of CONSTANT_P, force the SUBREG_REG into memory or
            register.

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

    (cherry picked from commit ea1c16f95b8fbaba4a7f3663ff9933ebedfb92a5)

  parent reply	other threads:[~2024-03-15 23:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-01  6:24 [Bug target/114184] New: ICE: in extract_insn, at recog.cc:2812 (unrecognizable insn ) with -Og -mavx512f and __builtin_memmove() _BitInt(256) zsojka at seznam dot cz
2024-03-01  9:54 ` [Bug target/114184] [12/13/14 Regression] ICE: in extract_insn, at recog.cc:2812 (unrecognizable insn ) with _Complex long double and vector VCE jakub at gcc dot gnu.org
2024-03-01  9:59 ` jakub at gcc dot gnu.org
2024-03-01 11:57 ` jakub at gcc dot gnu.org
2024-03-04  9:04 ` cvs-commit at gcc dot gnu.org
2024-03-04  9:09 ` [Bug target/114184] [12/13 " jakub at gcc dot gnu.org
2024-03-15 23:29 ` cvs-commit at gcc dot gnu.org [this message]
2024-03-18 14:40 ` [Bug target/114184] [12 " 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-114184-4-BTeefwEg1c@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).