BUG: Building with AVX2 support causes illegal instruction error on import

[salfter]

Describe the issue:

https://bugs.gentoo.org/972461#c31

I had AVX2 enabled on a Ryzen 7 3800X (aka Zen 2) host, which is supposed to support AVX2. After setting this in CPU_FLAGS_X86 and doing a full system rebuild, attempting to import numpy would crash with an illegal instruction error. This kept pybind11 (and some other packages) from building.

I ended up getting it working by disabling AVX2 for numpy and rebuilding numpy. Something like the following in /etc/portage/package.use will do:

dev-python/numpy CPU_FLAGS_X86: -avx2

Setting -fno-plt or -fplt in CPUFLAGS (as someone else had suggested) made no difference.

There was some speculation that gcc was doing something weird, but since whatever it is is affecting numpy in this way, you might want to look into it.

Reproduce the code example:

python -c 'import numpy'

Error message:

Illegal instruction

Python and NumPy Versions:

2.5.1
3.14.6 (main, Aug 26 2026, 11:38:32) [GCC 15.3.0]

Runtime Environment:

[{'numpy_version': '2.5.1',
'python': '3.14.6 (main, Aug 26 2026, 11:38:32) [GCC 15.3.0]',
'uname': uname_result(system='Linux', node='janeway', release='6.18.43-gentoo-dist-bin', version='#1 SMP PREEMPT_DYNAMIC Thu Aug 6 19:07:48 -00 2026', machine='x86_64')},
{'simd_extensions': {'baseline': ['X86_V2'],
'found': ['X86_V3'],
'not_found': ['X86_V4', 'AVX512_ICL', 'AVX512_SPR']}},
{'ignore_floating_point_errors_in_matmul': False},
{'available_backends': ['NETLIB', 'OPENBLAS'],
'current_backend': 'OPENBLAS',
'filepath': '/usr/lib64/libflexiblas.so.3.5',
'internal_api': 'flexiblas',
'loaded_backends': ['OPENBLAS'],
'num_threads': 16,
'prefix': 'libflexiblas',
'user_api': 'blas',
'version': '3.5.0'},
{'available_backends': ['NETLIB', 'OPENBLAS'],
'current_backend': 'OPENBLAS',
'filepath': '/usr/lib64/flexiblas/libflexiblas_fallback_lapack.so',
'internal_api': 'flexiblas',
'loaded_backends': ['OPENBLAS'],
'num_threads': 16,
'prefix': 'libflexiblas',
'user_api': 'blas',
'version': '3.5.0'},
{'architecture': 'ZEN',
'filepath': '/usr/lib64/libopenblas_zenp-r0.3.33.so',
'internal_api': 'openblas',
'num_threads': 16,
'prefix': 'libopenblas',
'threading_layer': 'openmp',
'user_api': 'blas',
'version': '0.3.33'},
{'filepath': '/usr/lib/gcc/x86_64-pc-linux-gnu/15/libgomp.so.1.0.0',
'internal_api': 'openmp',
'num_threads': 16,
'prefix': 'libgomp',
'user_api': 'openmp',
'version': None}]

How does this issue affect you or how did you find it:

It blocked installation/updates of any additional Python packages that depend on numpy.

[ngoldbaum]

Would you mind rebuilding the crashing configuration and then running it under gdb?

gdb --batch -ex run -ex bt -ex 'x/i $pc' --args python -c 'import numpy'

It would also be nice to see the output of

emerge --info dev-python/numpy

The first will show us exactly which instruction and spot in numpy or another library it's crashing on. The second will show us the exact flags and toolchain you're using to build NumPy.

[Ash20pk]

Some triage notes that may save time here. I haven't reproduced this (no Zen 2 Gentoo box), so everything below is from reading the linked bug and the ebuild — flagging clearly which parts are established vs. inferred.

The linked Gentoo bug is at least three different problems in one thread. Worth separating before treating them as one report:

1. Comments #26/#27 — with -fno-plt, the call to cblas_sdot gets its address computed as a bad %rip offset and jumps into garbage. sam split that out as bug 974853. Toolchain issue, not NumPy.
2. Comment #28 — an AVX-512 / Skylake case, which sam suspected was bug 971475.
3. This reporter (#31), who explicitly states -fno-plt and -fplt made no difference — so not case 1.

The CPU does support AVX2, and the show_runtime output above is from the working build, not the crashing one. It reports baseline: ['X86_V2'] with found: ['X86_V3']. Gentoo's ebuild maps cpu_flags_x86_avx2 → X86_V3 in -Dcpu-baseline, so a baseline of X86_V2 alone is the post-workaround (-avx2) build. That output is still useful though: found: ['X86_V3'] is NumPy's own runtime detection confirming the Ryzen 3800X really does have AVX2. So npy__cpu_validate_baseline() is not what's firing here, and this is a different animal from #30492.

Which means the workaround is weaker evidence than it looks: setting -avx2 changes -Dcpu-baseline for the entire module, so it rebuilds every translation unit with different codegen. "Disabling AVX2 fixes it" is equally consistent with a codegen bug in AVX2-compiled paths as it is with the CPU lacking AVX2 — and the runtime detection rules out the latter.

Two ebuild details worth confirming from the emerge --info you asked for, both from numpy-2.5.1.ebuild:

• It passes -Dcpu-baseline-detect=disabled. That's deliberate on Gentoo's part (it stops a global -march=native in CFLAGS from silently widening NumPy's baseline), but it also means the baseline NumPy records can be narrower than what GCC actually emits — -march= in the user's CFLAGS still lets the compiler use anything the target supports, in any translation unit. So NPY_WITH_CPU_BASELINE is not a reliable description of the emitted instruction set on Gentoo.
• -Dcpu-dispatch="$(usev cpudetection MAX)" — with USE=-cpudetection this expands to an empty cpu-dispatch, removing runtime dispatch entirely. It defaults on (+cpudetection), but it's cheap to rule out, and comment #29 suggests at least one person in that thread was toggling it.

Two additions to the gdb request that would help narrow it fast. From comment #20, someone else's dmesg on this bug showed trap invalid opcode ... in _multiarray_umath.cpython-313-x86_64-linux-gnu.so, so the fault is plausibly inside NumPy rather than OpenBLAS — but that was a different reporter's build, so it's worth re-establishing here. Alongside the backtrace:

# which library owns the faulting address, and is the opcode real or garbage?
gdb --batch -ex run -ex bt -ex 'info symbol $pc' -ex 'x/8i $pc-16' \
    -ex 'info sharedlibrary' --args python -c 'import numpy'

# does the fault survive with dispatch forced off?
NPY_DISABLE_CPU_FEATURES="AVX2 FMA3" python -c 'import numpy'

If x/8i shows a valid AVX2 instruction at $pc, that points at a genuine ISA/codegen problem; if it shows garbage or $pc sits mid-instruction, it's the same class as bug 974853 — a bad indirect call landing in the middle of a function — regardless of whether -fno-plt is the trigger this time. That distinction decides whether this is a NumPy bug at all, and it's the one thing the thread has never actually established.

Also worth recording the exact CFLAGS/-march and gcc --version (GCC 15.3.0 per the report) — cases 1 and 2 above both turned out to be toolchain-dependent.