https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113485
Bug ID: 113485
Summary: Segmentation fault in -fno-guess-branch-probability
optimization of NEON instructions on aarch64-linux-gnu
target
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: radek.barton at microsoft dot com
Target Milestone: ---
Created attachment 57140
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57140&action=edit
neon-issue.i
Hello everyone.
When code with certain combination of NEON instructions intrinsics is compiled
for `aarch64-linux-gnu` target with at least `-O1` optimizations enabled, the
compilation fails with:
```
during RTL pass: split1
neon-issue.c:23:1: internal compiler error: Segmentation fault
23 | }
| ^
0xdd5ac3 crash_signal
/home/blackhex/mingw-woarm64-build/code/gcc-master/gcc/toplev.cc:317
0x7f5e7aa0851f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x9e1c4d mark_label_nuses
/home/blackhex/mingw-woarm64-build/code/gcc-master/gcc/emit-rtl.cc:3896
0x9e1cca mark_label_nuses
/home/blackhex/mingw-woarm64-build/code/gcc-master/gcc/emit-rtl.cc:3907
0x9e1c99 mark_label_nuses
/home/blackhex/mingw-woarm64-build/code/gcc-master/gcc/emit-rtl.cc:3904
0x9e7779 try_split(rtx_def*, rtx_insn*, int)
/home/blackhex/mingw-woarm64-build/code/gcc-master/gcc/emit-rtl.cc:4093
0xd3fdd1 split_insn
/home/blackhex/mingw-woarm64-build/code/gcc-master/gcc/recog.cc:3405
0xd44daf split_all_insns()
/home/blackhex/mingw-woarm64-build/code/gcc-master/gcc/recog.cc:3509
0xd44e5c execute
/home/blackhex/mingw-woarm64-build/code/gcc-master/gcc/recog.cc:4433
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.
```
I've reproduced the issue on a recent master branch
(9a5e8f9d112adb0fdd0931f72a023cd77c09dd8c) from git://gcc.gnu.org/git/gcc.git
compiled with:
```
configure --prefix=/home/blackhex/cross-aarch64-linux-gnu-libc
--target=aarch64-linux-gnu
--includedir=/home/blackhex/cross-aarch64-linux-gnu-libc/aarch64-linux-gnu/include
--enable-languages=c,lto,c++,fortran --enable-shared --enable-static
--enable-graphite --enable-fully-dynamic-string
--enable-libstdcxx-filesystem-ts=yes --enable-libstdcxx-time=yes
--enable-cloog-backend=isl --enable-version-specific-runtime-libs --enable-lto
--enable-libgomp --enable-checking=release --disable-multilib --disable-shared
--disable-rpath --disable-werror --disable-symvers --disable-libstdcxx-pch
--disable-libstdcxx-debug --disable-isl-version-check --disable-bootstrap
--with-libiconv --with-system-zlib --with-gnu-as --with-gnu-ld --enable-debug
```
when building libjpeg-turbo.
I've managed to narrow down that this regression was introduced by
74e3e839ab2d368413207455af2fdaaacc73842b commit.
The issue is not reproducible when -fno-guess-branch-probability optimization
is disabled.
The minimum repro-case, I've found, is:
```
#include <arm_neon.h>
void test()
{
while (1)
{
static const uint16_t jsimd_rgb_ycc_neon_consts[] = {19595, 0, 0, 0, 0, 0,
0, 0};
uint16x8_t consts = vld1q_u16(jsimd_rgb_ycc_neon_consts);
uint8_t tmp_buf[0];
uint8x8x3_t input_pixels = vld3_u8(tmp_buf);
uint16x8_t r = vmovl_u8(input_pixels.val[1]);
uint32x4_t y_l = vmull_laneq_u16(vget_low_u16(r), consts, 0);
uint32x4_t s = vdupq_n_u32(1);
uint16x4_t a = vrshrn_n_u32(s, 16);
uint16x4_t y = vrshrn_n_u32(y_l, 16);
uint16x8_t ay = vcombine_u16(a, y);
unsigned char ***out_buf;
vst1_u8(out_buf[1][0], vmovn_u16(ay));
}
}
```
and the build command I used is:
```
/home/blackhex/cross-aarch64-linux-gnu-libc/bin/aarch64-linux-gnu-gcc \
-O1 -Wall -Wextra \
-c neon-issue.c \
-freport-bug -save-temps
```
I am attaching the repro-case with the header expanded.
Radek BartoĊ
