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)
GCC 10.2 is released, adjusting target milestone.
Started with r10-4373-gc265dfbf748e9fc3.
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.
Can't reproduce on trunk or the GCC 10 branch anymore.
Fixed on master with r11-2577-g229752afe3156a39.
Fixed. Well, the IL was certainly somewhat bogus and we're doing a better job now.