Failure on import (for older processor?)

[mhvk]

When I install in a fresh virtual environment, pip install numpy-quaddtype, which pulls in numpy 2.4.1, and then in python enter,

>>> from numpy_quaddtype import QuadPrecDType, QuadPrecision
Traceback (most recent call last):
  File "<python-input-0>", line 1, in <module>
    from numpy_quaddtype import QuadPrecDType, QuadPrecision
  File "/home/mhvk/temp/lib/python3.13/site-packages/numpy_quaddtype/__init__.py", line 1, in <module>
    from ._quaddtype_main import (
    ...<7 lines>...
    )
RuntimeError: Invalid slot with value 1031 passed in.

I also tried downgrading to numpy==2.40, but that did not change anything.

Further information as asked for in the numpy issue template:

import sys, numpy; print(numpy.__version__); print(sys.version)
2.4.0
3.13.11 (main, Dec  8 2025, 11:43:54) [GCC 15.2.0]

>>> import numpy; numpy.show_runtime()
[{'numpy_version': '2.4.0',
  'python': '3.13.11 (main, Dec  8 2025, 11:43:54) [GCC 15.2.0]',
  'uname': uname_result(system='Linux', node='swan.astro.utoronto.ca', release='6.17.13+deb14-amd64', version='#1 SMP PREEMPT_DYNAMIC Debian 6.17.13-1 (2025-12-20)', machine='x86_64')},
 {'simd_extensions': {'baseline': ['X86_V2'],
                      'found': [],
                      'not_found': ['X86_V3',
                                    'X86_V4',
                                    'AVX512_ICL',
                                    'AVX512_SPR']}},
 {'ignore_floating_point_errors_in_matmul': False},
 {'architecture': 'Sandybridge',
  'filepath': '/home/mhvk/temp/lib/python3.13/site-packages/numpy.libs/libscipy_openblas64_-fdde5778.so',
  'internal_api': 'openblas',
  'num_threads': 4,
  'prefix': 'libscipy_openblas',
  'threading_layer': 'pthreads',
  'user_api': 'blas',
  'version': '0.3.30'}]

I was worried that my ~2011 Sandy bridge might not support the X86_V2 baseline, but apparently that is only a problem for pre-2009 chips. Still, it might be related to having an old processor. I'll try on my much more recent laptop at home.

[ngoldbaum]

You might need to manually build numpy with an older baseline: numpy/numpy#30492 https://numpy.org/devdocs/building/cpu_simd.html

[ngoldbaum]

Oh wait, you're using an old release of quaddtype from pypi. We've been working on a new release for a while and there are a number of unreleased fixes.

I wonder if the pypi release is incompatible with the latest numpy.

Can you try building quaddtype from source?

[mhvk]

After building from source I do get "Illegal instruction":

# Just to check numpy itself is OK
>>> import numpy as np
>>> np.random.uniform(size=10)
array([0.12186179, 0.91292362, 0.5104251 , 0.86758895, 0.22895839,
       0.93034341, 0.2541247 , 0.1194776 , 0.63592968, 0.31096405])
# Try QuadDtype
>>> from numpy_quaddtype import QuadPrecDType, QuadPrecision
Illegal instruction        (core dumped) python

[SwayamInSync]

I wonder if the pypi release is incompatible with the latest numpy.

Yes the pypi version is not compatible with the numpy>=2.4

[ngoldbaum]

After building from source I do get "Illegal instruction":

Hmm, maybe this is coming from the SLEEF update?

[SwayamInSync]

from numpy_quaddtype import QuadPrecDType, QuadPrecision
Illegal instruction (core dumped) python

This is weird, I am sorry for the extra work but just to get the clean signal, can you please re-create the environment and delete all the old local clones and get a fresh one. When installing run the bash reinstall.sh as this will dump the build log into build_log.txt which might help me better pin-pointing the issue (if it persists)

[SwayamInSync]

My one wild guess

 {'simd_extensions': {'baseline': ['X86_V2'],
                      'found': [],
                      'not_found': ['X86_V3',
                                    'X86_V4',
                                    'AVX512_ICL',
                                    'AVX512_SPR']}},

We enforce all AVX instructions on x86-64 machines :) so this can also lead to illegal instruction, IIRC there was one similar issue in user-dtypes.
Oh its yours 😆 similar issue #40

[ngoldbaum]

Maybe we shouldn't ship wheels with AVX instructions if SLEEF's runtime checking isn't good enough.

I'm aware that will hurt performance but also we kind of have to target the lowest common denominator. AVX is in x86_64-v3, so by requiring AVX we're more stringent than numpy, which requires x86_64-v2 as of NumPy 2.4.

[SwayamInSync]

So basically in your system 'baseline': ['X86_V2'], only supports SSE instructions (which we enable) but also the AVX and FMA4 are enabled too (these are not found in your system)
So MAYBE the compiler may generate AVX/AVX2 instructions even in code paths that are supposed to be "SSE2-only"
I'll try to update the meson build to detect the available SIMD and enable/disable accordingly

[SwayamInSync]

Maybe we shouldn't ship wheels with AVX instructions if SLEEF's runtime checking isn't good enough.

There it is all hard-coded by the user, so we have to handle the detection :)

[mhvk]

Ah, that sounds like you found the underlying cause. In the meantime, I confirmed that reinstall.sh in a clean environment gave the same problem. Is there still a use for the build log? Just in case, it is at https://www.astro.utoronto.ca/~mhvk/build_log.txt

It would obviously be nice if the feature detection could parallel what is done in numpy... But perhaps only if it is easy -- my office computer should probably be replaced soon anyway...

[SwayamInSync]

I was reading SLEEF's SIMD detection and they had a weird thing in their build system

if(SLEEF_TARGET_PROCESSOR MATCHES "(x86|AMD64|amd64|^i.86$)")
  set(SLEEF_ARCH_X86 ON CACHE INTERNAL "True for x86 architecture.")

  set(CLANG_FLAGS_ENABLE_PURECFMA_SCALAR "-mavx2;-mfma")

They are setting -mavx2 -mfma (which is x86_64-v3) for PURECFMA_SCALAR unconditionally and there is no flag from which we can manipulate it from outside. Weird thing is that this is a scalar implementation, it wasn't supposed to be build with SIMD flags (from naming I can assume just FMA?) but still this remains v3

So even if I disable AVX still this will remain and I'm pretty sure this is the reason @mhvk getting illegal instruction. Should we raise this upstream? About maybe make it conditional so that we can modify by passing -D flags

[ngoldbaum]

Should we raise this upstream? About maybe make it conditional so that we can modify by passing -D flags

Sounds like that's the thing to do. Can meson apply patches to subprojects? We can do that as a hacky workaround for now.

[SwayamInSync]

Will it be possible to get a CI for testing? I am not sure about this maybe in Numpy we do on old processors?

[ngoldbaum]

We don't have anything like that in NumPy. I think it might require qemu?