[Bug target/99025] New: [11 Regression] ICE Segmentation fault since r11-6351-g12ae2bc70846a2be

[Bug target/99025] New: [11 Regression] ICE Segmentation fault since r11-6351-g12ae2bc70846a2be

[marxin at gcc dot gnu.org]

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

            Bug ID: 99025
           Summary: [11 Regression] ICE Segmentation fault since
                    r11-6351-g12ae2bc70846a2be
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: marxin at gcc dot gnu.org
                CC: wwwhhhyyy333 at gmail dot com
  Target Milestone: ---
              Host: x86_64-linux-gnu

The following ICEs, reduced from postgresql package:

$ cat pg_proc.i
long ProcedureCreate_values[16];
int ProcedureCreate_X;
union {
  float value;
  int retval;
} ProcedureCreate_myunion;

void
ProcedureCreate() {
  ProcedureCreate_myunion.value = ProcedureCreate_X;
  ProcedureCreate_values[6 - 1] = ProcedureCreate_myunion.retval;
  float X;
  union {
    float value;
    int retval;
  } myunion;
  myunion.value = X;
  ProcedureCreate_values[7 - 1] = myunion.retval;
}

$ gcc pg_proc.i -c -O3 -march=haswell
during RTL pass: expand
pg_proc.i: In function ‘ProcedureCreate’:
pg_proc.i:19:1: internal compiler error: Segmentation fault
   19 | }
      | ^
0xe7b97a crash_signal
        /home/marxin/Programming/gcc/gcc/toplev.c:327
0xcb5b3b mark_jump_label_1
        /home/marxin/Programming/gcc/gcc/jump.c:1097
0xcb5bd3 mark_jump_label_1
        /home/marxin/Programming/gcc/gcc/jump.c:1221
0xcb5bd3 mark_jump_label_1
        /home/marxin/Programming/gcc/gcc/jump.c:1221
0xcb5bd3 mark_jump_label_1
        /home/marxin/Programming/gcc/gcc/jump.c:1221
0xcb605d mark_all_labels
        /home/marxin/Programming/gcc/gcc/jump.c:332
0xcb605d rebuild_jump_labels_1
        /home/marxin/Programming/gcc/gcc/jump.c:74
0x9d36b4 execute
        /home/marxin/Programming/gcc/gcc/cfgexpand.c:6779
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.

[Bug target/99025] [11 Regression] ICE Segmentation fault since r11-6351-g12ae2bc70846a2be

[marxin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
           Priority|P3                          |P1
      Known to fail|                            |11.0
             Status|UNCONFIRMED                 |NEW
      Known to work|                            |10.2.0
   Target Milestone|---                         |11.0
   Last reconfirmed|                            |2021-02-09

[Bug target/99025] [11 Regression] ICE Segmentation fault since r11-6351-g12ae2bc70846a2be

[jakub at gcc dot gnu.org]

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

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

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

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

Untested fix.
The problem is that when simplify_gen_subreg is called on a SUBREG and
simplify_subreg fails to simplify it, because of mismatching element mode as
well as mismatching size, then simplify_gen_subreg just returns NULL instead of
creating the subreg.  The patch forces those SUBREGs into regs so that
simplify_gen_subreg will then always work.

[Bug target/99025] [11 Regression] ICE Segmentation fault since r11-6351-g12ae2bc70846a2be

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak <ubizjak at gmail dot com> ---
Comment on attachment 50154
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50154
gcc11-pr99025.patch

>2021-02-09  Jakub Jelinek  <jakub@redhat.com>

>+  if (SUBREG_P (operands[1]))
>+    operands[1] = force_reg (V2SFmode, operands[1]);

There is no need to check for SUBREG, force_reg has early exit in case operand
is already a register.

[Bug target/99025] [11 Regression] ICE Segmentation fault since r11-6351-g12ae2bc70846a2be

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Uroš Bizjak from comment #2)
> Comment on attachment 50154 [details]
> gcc11-pr99025.patch
> 
> >2021-02-09  Jakub Jelinek  <jakub@redhat.com>
> 
> >+  if (SUBREG_P (operands[1]))
> >+    operands[1] = force_reg (V2SFmode, operands[1]);
> 
> There is no need to check for SUBREG, force_reg has early exit in case
> operand is already a register.

I know, I've just misread nonimmediate_operand as nonmemory_operand and thought
I need to let immediates get through to simplify_gen_subreg.
The predicates are register_operand (so REG or SUBREG) or nonimmediate_operand
(so REG, SUBREG or MEM and in that case this is used in !MEM_P paths) and so
you're right force_reg can be called unconditionally.

[Bug target/99025] [11 Regression] ICE Segmentation fault since r11-6351-g12ae2bc70846a2be

[cvs-commit at gcc dot gnu.org]

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

--- 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:20482cfcc1d3b71e0aec57b5b48685bf0b5402ca

commit r11-7177-g20482cfcc1d3b71e0aec57b5b48685bf0b5402ca
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Feb 10 19:50:11 2021 +0100

    i386: Fix ICEs due to simplify_gen_subreg returning NULL [PR99025]

    In these patterns, we call simplify_gen_subreg on the input operand
    to create paradoxical subregs that have 2x, 4x or 8x elements as the input
    operand.  That works fine if the input operand is a REG, but when it is a
    SUBREG, RTL doesn't allow SUBREG of SUBREG and so relies on simplify_subreg
    actually simplifying it.  And e.g. if the input operand is a SUBREG that
    changes the element mode (floating vs. non-floating) and then combined with
    a paradoxical subreg (i.e. different size) this can easily fail, then
    simplify_gen_subreg returns NULL but we still use it in instructions.

    Fixed by forcing the operands into REG.

    2021-02-10  Jakub Jelinek  <jakub@redhat.com>

            PR target/99025
            * config/i386/sse.md (fix<fixunssuffix>_truncv2sfv2di2,
            <insn>v8qiv8hi2, <insn>v8qiv8si2, <insn>v4qiv4si2, <insn>v4hiv4si2,
            <insn>v8qiv8di2, <insn>v4qiv4di2, <insn>v2qiv2di2, <insn>v4hiv4di2,
            <insn>v2hiv2di2, <insn>v2siv2di2): Force operands[1] into REG
before
            calling simplify_gen_subreg on it.

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

[Bug target/99025] [11 Regression] ICE Segmentation fault since r11-6351-g12ae2bc70846a2be

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.