public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/94435] New: ICE in extract_insn, at recog.c:2294
@ 2020-04-01  9:16 marxin at gcc dot gnu.org
  2020-04-01  9:16 ` [Bug target/94435] " marxin at gcc dot gnu.org
                   ` (7 more replies)
  0 siblings, 8 replies; 9+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-04-01  9:16 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 94435
           Summary: ICE in extract_insn, at recog.c:2294
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: marxin at gcc dot gnu.org
                CC: jakub at gcc dot gnu.org
  Target Milestone: ---
              Host: x86_64-linux-gnu
            Target: aarch64-linux-gnu

Once Jakub added a new test-case I see:

$ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr94368.c
-moutline-atomics -c
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr94368.c: In function ‘bar’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr94368.c:25:1: error:
unrecognizable insn:
   25 | }
      | ^
(insn 62 61 63 8 (set (reg:CC 66 cc)
        (compare:CC (reg:SI 0 x0)
            (reg:HI 122)))
"/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr94368.c":23:7 -1
     (nil))
during RTL pass: vregs
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr94368.c:25:1: internal
compiler error: in extract_insn, at recog.c:2294
0x119b89f _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
        /home/marxin/Programming/gcc2/gcc/rtl-error.c:108
0x119b8e0 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
        /home/marxin/Programming/gcc2/gcc/rtl-error.c:116
0x114a983 extract_insn(rtx_insn*)
        /home/marxin/Programming/gcc2/gcc/recog.c:2294
0xdb0281 instantiate_virtual_regs_in_insn
        /home/marxin/Programming/gcc2/gcc/function.c:1607
0xdb1859 instantiate_virtual_regs
        /home/marxin/Programming/gcc2/gcc/function.c:1977
0xdb1924 execute
        /home/marxin/Programming/gcc2/gcc/function.c:2026
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

The issues started with r10-3301-g3950b229a5ed6710f30241c2ddc3c74909bf4740
where -moutline-atomics was added.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/94435] ICE in extract_insn, at recog.c:2294
  2020-04-01  9:16 [Bug target/94435] New: ICE in extract_insn, at recog.c:2294 marxin at gcc dot gnu.org
@ 2020-04-01  9:16 ` marxin at gcc dot gnu.org
  2020-04-01  9:39 ` jakub at gcc dot gnu.org
                   ` (6 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-04-01  9:16 UTC (permalink / raw)
  To: gcc-bugs

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2020-04-01
             Status|UNCONFIRMED                 |NEW
                 CC|                            |rth at gcc dot gnu.org
   Target Milestone|---                         |10.0
      Known to fail|                            |10.0

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/94435] ICE in extract_insn, at recog.c:2294
  2020-04-01  9:16 [Bug target/94435] New: ICE in extract_insn, at recog.c:2294 marxin at gcc dot gnu.org
  2020-04-01  9:16 ` [Bug target/94435] " marxin at gcc dot gnu.org
@ 2020-04-01  9:39 ` jakub at gcc dot gnu.org
  2020-04-01 21:01 ` [Bug target/94435] [9/10 Regression] " pinskia at gcc dot gnu.org
                   ` (5 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-04-01  9:39 UTC (permalink / raw)
  To: gcc-bugs

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 48156
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48156&action=edit
gcc10-pr94435.patch

Untested fix.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/94435] [9/10 Regression] ICE in extract_insn, at recog.c:2294
  2020-04-01  9:16 [Bug target/94435] New: ICE in extract_insn, at recog.c:2294 marxin at gcc dot gnu.org
  2020-04-01  9:16 ` [Bug target/94435] " marxin at gcc dot gnu.org
  2020-04-01  9:39 ` jakub at gcc dot gnu.org
@ 2020-04-01 21:01 ` pinskia at gcc dot gnu.org
  2020-04-02 10:55 ` cvs-commit at gcc dot gnu.org
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2020-04-01 21:01 UTC (permalink / raw)
  To: gcc-bugs

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[10 Regression] ICE in      |[9/10 Regression] ICE in
                   |extract_insn, at            |extract_insn, at
                   |recog.c:2294                |recog.c:2294
   Target Milestone|10.0                        |9.4

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The patch which introduced this was just backported to GCC 9 today:
g:9cf2784a69e126283c33fdbcfbf5713106e87479 .

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/94435] [9/10 Regression] ICE in extract_insn, at recog.c:2294
  2020-04-01  9:16 [Bug target/94435] New: ICE in extract_insn, at recog.c:2294 marxin at gcc dot gnu.org
                   ` (2 preceding siblings ...)
  2020-04-01 21:01 ` [Bug target/94435] [9/10 Regression] " pinskia at gcc dot gnu.org
@ 2020-04-02 10:55 ` cvs-commit at gcc dot gnu.org
  2020-04-02 10:57 ` cvs-commit at gcc dot gnu.org
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-04-02 10:55 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #3 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:66e327517b10a19690a470c8dccfa363ba061022

commit r10-7513-g66e327517b10a19690a470c8dccfa363ba061022
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Apr 2 12:54:47 2020 +0200

    aarch64: Fix ICE due to aarch64_gen_compare_reg_maybe_ze [PR94435]

    The following testcase ICEs, because aarch64_gen_compare_reg_maybe_ze emits
    invalid RTL.
    For y_mode [QH]Imode it expects y to be of that mode (or CONST_INT that
fits
    into that mode) and x being SImode; for non-CONST_INT y it zero extends y
    into SImode and compares that against x, for CONST_INT y it zero extends y
    into SImode.  The problem is that when the zero extended constant isn't
    usable directly, it forces it into a REG, but with y_mode mode, and then
    compares against y.  That is wrong, because it should force it into a
SImode
    REG and compare that way.

    2020-04-02  Jakub Jelinek  <jakub@redhat.com>

            PR target/94435
            * config/aarch64/aarch64.c (aarch64_gen_compare_reg_maybe_ze): For
            y_mode E_[QH]Imode and y being a CONST_INT, change y_mode to
SImode.

            * gcc.target/aarch64/pr94435.c: New test.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/94435] [9/10 Regression] ICE in extract_insn, at recog.c:2294
  2020-04-01  9:16 [Bug target/94435] New: ICE in extract_insn, at recog.c:2294 marxin at gcc dot gnu.org
                   ` (3 preceding siblings ...)
  2020-04-02 10:55 ` cvs-commit at gcc dot gnu.org
@ 2020-04-02 10:57 ` cvs-commit at gcc dot gnu.org
  2020-04-02 10:59 ` cvs-commit at gcc dot gnu.org
                   ` (2 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-04-02 10:57 UTC (permalink / raw)
  To: gcc-bugs

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

--- 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:df562b12d90699c20923f91df48eed08ebcb572e

commit r10-7514-gdf562b12d90699c20923f91df48eed08ebcb572e
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Apr 2 12:57:11 2020 +0200

    aarch64: Fix ICE due to aarch64_gen_compare_reg_maybe_ze [PR94435]

    The following testcase ICEs, because aarch64_gen_compare_reg_maybe_ze emits
    invalid RTL.
    For y_mode [QH]Imode it expects y to be of that mode (or CONST_INT that
fits
    into that mode) and x being SImode; for non-CONST_INT y it zero extends y
    into SImode and compares that against x, for CONST_INT y it zero extends y
    into SImode.  The problem is that when the zero extended constant isn't
    usable directly, it forces it into a REG, but with y_mode mode, and then
    compares against y.  That is wrong, because it should force it into a
SImode
    REG and compare that way.

    2020-04-02  Jakub Jelinek  <jakub@redhat.com>

            PR target/94435
            * config/aarch64/aarch64.c (aarch64_gen_compare_reg_maybe_ze): For
            y_mode E_[QH]Imode and y being a CONST_INT, change y_mode to
SImode.

            * gcc.target/aarch64/pr94435.c: New test.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/94435] [9/10 Regression] ICE in extract_insn, at recog.c:2294
  2020-04-01  9:16 [Bug target/94435] New: ICE in extract_insn, at recog.c:2294 marxin at gcc dot gnu.org
                   ` (4 preceding siblings ...)
  2020-04-02 10:57 ` cvs-commit at gcc dot gnu.org
@ 2020-04-02 10:59 ` cvs-commit at gcc dot gnu.org
  2020-04-02 11:00 ` jakub at gcc dot gnu.org
  2020-04-22 16:10 ` cvs-commit at gcc dot gnu.org
  7 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-04-02 10:59 UTC (permalink / raw)
  To: gcc-bugs

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

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

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

commit r9-8442-gbe64fc4cab7facee309447302b6ee7616dfe60b4
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Apr 2 12:54:47 2020 +0200

    aarch64: Fix ICE due to aarch64_gen_compare_reg_maybe_ze [PR94435]

    The following testcase ICEs, because aarch64_gen_compare_reg_maybe_ze emits
    invalid RTL.
    For y_mode [QH]Imode it expects y to be of that mode (or CONST_INT that
fits
    into that mode) and x being SImode; for non-CONST_INT y it zero extends y
    into SImode and compares that against x, for CONST_INT y it zero extends y
    into SImode.  The problem is that when the zero extended constant isn't
    usable directly, it forces it into a REG, but with y_mode mode, and then
    compares against y.  That is wrong, because it should force it into a
SImode
    REG and compare that way.

    2020-04-02  Jakub Jelinek  <jakub@redhat.com>

            PR target/94435
            * config/aarch64/aarch64.c (aarch64_gen_compare_reg_maybe_ze): For
            y_mode E_[QH]Imode and y being a CONST_INT, change y_mode to
SImode.

            * gcc.target/aarch64/pr94435.c: New test.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/94435] [9/10 Regression] ICE in extract_insn, at recog.c:2294
  2020-04-01  9:16 [Bug target/94435] New: ICE in extract_insn, at recog.c:2294 marxin at gcc dot gnu.org
                   ` (5 preceding siblings ...)
  2020-04-02 10:59 ` cvs-commit at gcc dot gnu.org
@ 2020-04-02 11:00 ` jakub at gcc dot gnu.org
  2020-04-22 16:10 ` cvs-commit at gcc dot gnu.org
  7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-04-02 11:00 UTC (permalink / raw)
  To: gcc-bugs

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.  Will need to be backported to 8 once -moutline-atomics is backported
there.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/94435] [9/10 Regression] ICE in extract_insn, at recog.c:2294
  2020-04-01  9:16 [Bug target/94435] New: ICE in extract_insn, at recog.c:2294 marxin at gcc dot gnu.org
                   ` (6 preceding siblings ...)
  2020-04-02 11:00 ` jakub at gcc dot gnu.org
@ 2020-04-22 16:10 ` cvs-commit at gcc dot gnu.org
  7 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-04-22 16:10 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-8 branch has been updated by Andre Simoes Dias Vieira
<avieira@gcc.gnu.org>:

https://gcc.gnu.org/g:1dbd821ee74e6c234e61e25b0801a0b0949bcc67

commit r8-10214-g1dbd821ee74e6c234e61e25b0801a0b0949bcc67
Author: Andre Vieira <andre.simoesdiasvieira@arm.com>
Date:   Thu Apr 16 10:16:18 2020 +0100

    aarch64: Fix ICE due to aarch64_gen_compare_reg_maybe_ze [PR94435]

    The following testcase ICEs, because aarch64_gen_compare_reg_maybe_ze emits
    invalid RTL.
    For y_mode [QH]Imode it expects y to be of that mode (or CONST_INT that
fits
    into that mode) and x being SImode; for non-CONST_INT y it zero extends y
    into SImode and compares that against x, for CONST_INT y it zero extends y
    into SImode.  The problem is that when the zero extended constant isn't
    usable directly, it forces it into a REG, but with y_mode mode, and then
    compares against y.  That is wrong, because it should force it into a
SImode
    REG and compare that way.

    2020-04-16  Andre Vieira  <andre.simoesdiasvieira@arm.com>

            Backport from mainline
            2020-04-02  Jakub Jelinek  <jakub@redhat.com>

            PR target/94435
            * config/aarch64/aarch64.c (aarch64_gen_compare_reg_maybe_ze): For
            y_mode E_[QH]Imode and y being a CONST_INT, change y_mode to
SImode.

            * gcc.target/aarch64/pr94435.c: New test.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2020-04-22 16:10 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-01  9:16 [Bug target/94435] New: ICE in extract_insn, at recog.c:2294 marxin at gcc dot gnu.org
2020-04-01  9:16 ` [Bug target/94435] " marxin at gcc dot gnu.org
2020-04-01  9:39 ` jakub at gcc dot gnu.org
2020-04-01 21:01 ` [Bug target/94435] [9/10 Regression] " pinskia at gcc dot gnu.org
2020-04-02 10:55 ` cvs-commit at gcc dot gnu.org
2020-04-02 10:57 ` cvs-commit at gcc dot gnu.org
2020-04-02 10:59 ` cvs-commit at gcc dot gnu.org
2020-04-02 11:00 ` jakub at gcc dot gnu.org
2020-04-22 16:10 ` cvs-commit at gcc dot gnu.org

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).