[Bug c/100793] New: ICE: in expand_assignment, at expr.c:5363

[Bug c/100793] New: ICE: in expand_assignment, at expr.c:5363

[cnsun at uwaterloo dot ca]

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

            Bug ID: 100793
           Summary: ICE: in expand_assignment, at expr.c:5363
           Product: gcc
           Version: tree-ssa
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: cnsun at uwaterloo dot ca
  Target Milestone: ---

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210527 (experimental) [master revision
:d03f010a0:01c59ef2e5a59b44d2b662361196abb6be872a20] (GCC)

$ cat mutant.c
f4() {
  register a;
  register __attribute__((vector_size(16))) b __asm("xmm17");
  b[a] = a;
  asm("" : "+v"(b));
}

$ gcc-trunk  mutant.c
mutant.c:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
    1 | f4() {
      | ^~
mutant.c: In function ‘f4’:
mutant.c:2:12: warning: type defaults to ‘int’ in declaration of ‘a’
[-Wimplicit-int]
    2 |   register a;
      |            ^
mutant.c:3:45: warning: type defaults to ‘int’ in declaration of ‘b’
[-Wimplicit-int]
    3 |   register __attribute__((vector_size(16))) b __asm("xmm17");
      |                                             ^
mutant.c:3:45: error: the register specified for ‘b’ cannot be accessed by the
current target
during RTL pass: expand
mutant.c:4:8: internal compiler error: in expand_assignment, at expr.c:5363
    4 |   b[a] = a;
      |   ~~~~~^~~
0x6b2f16 expand_assignment(tree_node*, tree_node*, bool)
        /tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/expr.c:5363
0xa4307f expand_gimple_stmt_1
        /tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/cfgexpand.c:3916
0xa4307f expand_gimple_stmt
        /tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/cfgexpand.c:4014
0xa49159 expand_gimple_basic_block
        /tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/cfgexpand.c:6056
0xa4b02f execute
        /tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/cfgexpand.c:6782
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 middle-end/100793] ICE: in expand_assignment, at expr.c:5363

[roger at nextmovesoftware dot com]

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

Roger Sayle <roger at nextmovesoftware dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-12-29
     Ever confirmed|0                           |1
           Keywords|error-recovery,             |ice-on-valid-code
                   |ice-on-invalid-code         |
             Status|UNCONFIRMED                 |NEW
                 CC|                            |roger at nextmovesoftware dot com

--- Comment #1 from Roger Sayle <roger at nextmovesoftware dot com> ---
A slight variation on the original, reveals that this issue is slightly more
serious than it first appears.

void f4() {
  int a;
  register int __attribute__((vector_size(16))) b __asm("xmm1");
  b[a] = a;
  asm("" : "+v"(b));
}

ICEs without issuing any error/warning at -O2 (so not an error recovery issue),
but also compiles fine if "-mavx2" is specified (so is valid for some
architectures).  This is related to PR middle-end/80162, indeed the test case
testsuite/c-c++-common/pr80162-2.c ICEs if compiled without -mavx2.

Variable index addressing of a vector register can be implemented, without
hardware support, by spilling the register to memory, but the problematic
assert insist that this ARRAY_REF is indexed by a CONST_INT.