Reduced test: --- struct DArray { __SIZE_TYPE__ length; int* ptr; }; void foo35(DArray) { static __thread int x[5]; foo35({5, (int*)&x}); } --- during RTL pass: ira test.cc: In function ‘void foo35(DArray)’: test.cc:11:1: internal compiler error: in update_equiv_regs, at ira.c:3425 0xbe1223 update_equiv_regs /build/aarch64-linux-gnu/build/gcc/ira.c:3425 0xbe6bf0 ira /build/aarch64-linux-gnu/build/gcc/ira.c:5226 0xbe6bf0 execute /build/aarch64-linux-gnu/build/gcc/ira.c:5581 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. --- Reading specs from /build/aarch64-linux-gnu/build/build/gcc/specs COLLECT_GCC=/build/aarch64-linux-gnu/build/build/gcc/xg++ COLLECT_LTO_WRAPPER=/build/aarch64-linux-gnu/build/build/gcc/lto-wrapper Target: aarch64-linux-gnu Configured with: /build/aarch64-linux-gnu/build/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --with-sysroot=/ --enable-languages=c++,lto --enable-checking --enable-link-mutex --disable-bootstrap --disable-werror --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libitm --disable-libsanitizer --disable-multilib --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=aarch64-linux-gnu --with-native-system-header-dir=/usr/aarch64-linux-gnu/include Thread model: posix gcc version 8.0.0 20170625 (experimental) (GCC) --- I have checked an arm64 cross compiler for gcc 5.4.0, and can reproduce the same ICE (https://godbolt.org/g/YRXfyY), it could go back even further. Also tested on against other targets - alpha, arm, hppa, mips, m68k, ppc, ppcspe, sparc, sh, s390 - can not reproduce the ICE on any of them. It only seems to be arm64 that's affected.
Confirmed on all released GCC versions supporting aarch64. Only ICEs on aarch64-linux targets, not bare-metal I suspect the REG_EQUIV notes that we add in the aarch64 backend in the TLS symbol handling code are to blame.
I can repeat this bug on aarch64 machine with the latest gcc. I am taking a deeper study on this one now. let me know if you are currently working on the fix of this one.
if the DEST is NOT a REG (sometimes it's a SUBREG, for example in the testing case of this Bug), the REG_EQUIV notes should NOT be added.
Author: paolo Date: Wed Oct 11 19:43:54 2017 New Revision: 253657 URL: https://gcc.gnu.org/viewcvs?rev=253657&root=gcc&view=rev Log: /gcc 2017-10-11 Qing Zhao <qing.zhao@oracle.com> PR target/81422 * config/aarch64/aarch64.c (aarch64_load_symref_appropriately): Check whether the dest is REG before adding REG_EQUIV note. /gcc/testsuite 2017-10-11 Qing Zhao <qing.zhao@oracle.com> PR target/81422 * gcc.target/aarch64/pr81422.C: New test. Added: trunk/gcc/testsuite/gcc.target/aarch64/pr81422.C Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.c trunk/gcc/testsuite/ChangeLog
Fixed.
Confirmed, I can see that tests have started passing on my side. Thanks!