The problem seems to be in boolean indexing.

Can you share a gdb traceback?

Can you share a gdb traceback?

I was going to wait on the next GCC 15 version. Fedora (and Linus!) jumped the gun in using 15 in a release.

I can reproduce segfaults on a small chunk of the testsuite (and, well, in production, which is what led me to double-check ;p) with GCC 15.1.0 over here, too, FWIW (Gentoo Linux, x64, on a zen4 CPU). Everything passes w/ GCC 14.x (right now, 14.3.0).

Will see about getting some traces in the next few days.

I was going to wait on the next GCC 15 version. Fedora (and Linus!) jumped the gun in using 15 in a release.

Fedora only shipped it briefly before the final release. The next GCC 15 release will be in a couple of months, then it goes to yearly (same schedule as usual). It's best if it turns out to be a GCC bug to get it reported before that next one. Otherwise, relying on the fix being out there takes way longer.

I tried to reproduce this in the following environments:

• on my regular Gentoo workstation using GCC trunk but with -O3 -march=znver2 -flto with our numpy-2.2.6 package's testsuite
• in a clean Gentoo container running stable but with GCC 15 installed and in-use to build our numpy-2.5.5 package's testsuite
• in a Fedora 42 container (fedora:42 with Docker) on a git clone of main using spin test
  and all of them worked.

@NiLuJe Feel free to file a bug on the Gentoo side so we can dig into it a bit there and see if we can come up with something to share on this side if there's nothing obvious we find here. If you do, please include the testsuite results when run via the ebuild (inc. build.log) and emerge --info. Thanks!

• on my regular Gentoo workstation using GCC trunk but with -O3 -march=znver2 -flto with our numpy-2.2.6 package's testsuite

That was an interesting observation!

I'm using -O3 -march=native (so ~ znver4)... and, indeed, it passes w/ znver2, it passes w/ znver3.... and it fails with znver4!

LTO doesn't affect the result, but, unsurprisingly (somewhat? I was under the impression that the buildsystem enforced O3 anyway?), -O3 does: it passes w/ -O2 -march=znver4.

I'll file that on the Gentoo side w/ the logs.

I'll file that on the Gentoo side w/ the logs.

Here it is: https://bugs.gentoo.org/956770

I've found using -march=native triggers the error, as do -march=x86-64-v4 and -march=znver5. Omitting -march altogether works. For the record, I have an AMD Zen5 cpu.

I'm suspecting a conflict with either meson or the dispatcher. The lesson might be: don't use -march.

Summarising findings from the Gentoo side: it's a numpy bug.

Thread 1 "python3.13" received signal SIGSEGV, Segmentation fault.
0x00007ffff47df6d9 in npy_memchr (haystack=0x7fffe8835d07 "", needle=0 '\000', stride=1, size=514, psubloopsize=0x7fffffffa160, invert=1) at ../numpy-2.2.6/numpy/_core/src/multiarray/common.h:278
278                     if (v != 0) {
(gdb) bt
#0  0x00007ffff47df6d9 in npy_memchr (haystack=0x7fffe8835d07 "", needle=0 '\000', stride=1, size=514, psubloopsize=0x7fffffffa160, invert=1) at ../numpy-2.2.6/numpy/_core/src/multiarray/common.h:278
#1  array_boolean_subscript (self=self@entry=0x7fffec1c65b0, bmask=<optimized out>, order=order@entry=NPY_CORDER) at ../numpy-2.2.6/numpy/_core/src/multiarray/mapping.c:1022
[...]

Looking at npy_memchr, I see UBSAN gets suppressed at

(It actually looks quite similar to what subversion was doing: https://bugs.gentoo.org/950271).

Changing https://github.com/numpy/numpy/blob/main/numpy/_core/include/numpy/npy_cpu.h#L128 to set #define NPY_ALIGNMENT_REQUIRED 1 works for Kostadin who could hit it otherwise.

I recommend ripping all of that out and always assuming NPY_ALIGNMENT_REQUIRED. You'll run into random issues like this otherwise with increasing frequency.

Thanks for the deep dive! Ping @seberg - it looks like you added the suppression in 2022.

🤷 this is ancient code, I just added the ignore because the variable is supposed to be set when we know unaligned access is supported and also it clearly was supported on all systems UBSAN ever ran on.

I don't care for keeping NPY_ALIGNEMENT_REQUIRED around (it probably makes a bit of a difference for structured dtypes only). It's just in one corner of NumPy and not used for a large chunk NumPy runs.

While I doubt it is important, I do think that this did/does make some sense here (no idea how much), in subversion, and I am very sure I also saw it in linux kernel code.
The pattern is 10+ years old in NumPy, and while I don't know if the define could be smarter, I doubt we will be the last project that runs into it.

Could be that gcc is using SIMD instructions that expect alignment.

Could be that gcc is using SIMD instructions that expect alignment.

It's precisely that, yeah. GCC will even peel for alignment now to handle misaligned workloads.

While I doubt it is important, I do think that this did/does make some sense here (no idea how much), in subversion, and I am very sure I also saw it in linux kernel code.

Right, it was absolutely a reasonable thing to do and it would've given a nice boost in the past. On the other hand, it's always a pain when you start debugging something and realise it's an #ifdef away from being legal ;)

It's just at odds with expecting compilers to autovectorise things these days. I recommend just dropping all of it, and if there's performance regressions, we can look into those if-and-when.