Bug 96263 - [10/11 Regression] ICE: in lra_assign, at lra-assigns.c:1648 with -O -flive-range-shrinkage -fnon-call-exceptions -msse4 --param=max-sched-ready-insns=1 since r10-4373-gc265dfbf748e9fc3
Summary: [10/11 Regression] ICE: in lra_assign, at lra-assigns.c:1648 with -O -flive-r...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 11.0
: P3 normal
Target Milestone: 10.3
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code, missed-optimization, ra
Depends on:
Blocks:
 
Reported: 2020-07-21 10:49 UTC by Zdenek Sojka
Modified: 2021-01-14 09:05 UTC (History)
2 users (show)

See Also:
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Build:
Known to work:
Known to fail: 10.0, 11.0
Last reconfirmed: 2020-07-23 00:00:00


Attachments
reduced testcase (367 bytes, text/plain)
2020-07-21 10:49 UTC, Zdenek Sojka
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Zdenek Sojka 2020-07-21 10:49:52 UTC
Created attachment 48904 [details]
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -flive-range-shrinkage -fnon-call-exceptions -msse4 --param=max-sched-ready-insns=1 testcase.c 
testcase.c: In function 'm':
testcase.c:12:1: warning: AVX512F vector return without AVX512F enabled changes the ABI [-Wpsabi]
   12 | a m(unsigned short n, __int128 o) {
      | ^
during RTL pass: reload
testcase.c:27:1: internal compiler error: in lra_assign, at lra-assigns.c:1648
   27 | }
      | ^
0xefe25b lra_assign(bool&)
        /repo/gcc-trunk/gcc/lra-assigns.c:1648
0xef7f3c lra(_IO_FILE*)
        /repo/gcc-trunk/gcc/lra.c:2465
0xea7949 do_reload
        /repo/gcc-trunk/gcc/ira.c:5525
0xea7949 execute
        /repo/gcc-trunk/gcc/ira.c:5711
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.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r11-2246-20200721142816-gc850a642e1d-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r11-2246-20200721142816-gc850a642e1d-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20200721 (experimental) (GCC)
Comment 1 Richard Biener 2020-07-23 06:51:49 UTC
GCC 10.2 is released, adjusting target milestone.
Comment 2 Martin Liška 2020-07-23 10:41:08 UTC
Started with r10-4373-gc265dfbf748e9fc3.
Comment 3 Richard Biener 2020-07-23 11:17:03 UTC
veclower, esp. VEC_COND_EXPR lowering certainly makes a mess out of the testcase
(doing component-wise rather than smaller-vector size operations).  Also
somehow doing odd things like

  _5 = {e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e
.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_
6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, 
e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4
_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6,
 e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6};
   f.68_7 = f;
-  r_74 = _5 & f.68_7;
+  _35 = {e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, 
e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4
_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6,
 e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.
4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6
, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6};
+  _38 = BIT_FIELD_REF <_35, 128, 0>;
+  _40 = BIT_FIELD_REF <f.68_7, 128, 0>;
+  _43 = _38 & _40;
+  _45 = {e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, 
e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6};
+  _85 = BIT_FIELD_REF <_45, 128, 128>;
+  _56 = BIT_FIELD_REF <f.68_7, 128, 128>;
+  _61 = _56 & _85;
...

that _35 is v64qi.  Eventually the removed folding made a smaller CTOR from it,
but re-emitting the CTOR makes no sense at all.  Luckily we clean that up
(I have no hopes for -O0 though).  We should make veclower behave more
sanely.

But the change probably just exposed a latent bug.
Comment 4 Richard Biener 2020-10-12 12:45:55 UTC
Can't reproduce on trunk or the GCC 10 branch anymore.
Comment 5 Martin Liška 2020-10-12 12:48:04 UTC
Fixed on master with r11-2577-g229752afe3156a39.
Comment 6 Richard Biener 2021-01-14 09:05:20 UTC
Fixed.  Well, the IL was certainly somewhat bogus and we're doing a better job now.