BLD/MAINT: improve support for Intel LLVM compilers - #31389
Merged
Conversation
With these changes, downstream users wanting to use the Intel compilers can do so when linking against NumPy headers. Also include a build change for NumPy itself that is clearly correct: Intel compilers do not use `_Fcomplex` & co for complex types, but the regular C99 complex.h types. Taken over from PR 25044 Closes numpygh-25044 Closes numpygh-31337 (reports the same `_Fcomplex` issue) Co-authored-by: Matti Picus <[email protected]>
seberg
approved these changes
May 5, 2026
seberg
left a comment
Member
There was a problem hiding this comment.
Thanks, LGTM, and as per discussion on the issue an important fix for intel compilers.
tylerjereddy
reviewed
May 5, 2026
| typedef _Fcomplex npy_cfloat; | ||
| typedef _Lcomplex npy_clongdouble; | ||
| #else /* !defined(_MSC_VER) || defined(__INTEL_COMPILER) */ | ||
| #else /* !defined(_MSC_VER) || defined(__INTEL_COMPILER) && !defined(__INTEL_LLVM_COMPILER) */ |
Contributor
There was a problem hiding this comment.
minor: I suppose the final conditional in the comment should be inverted like its neighbors relative to above with a preceding ||
Member
Author
There was a problem hiding this comment.
Ah indeed. Doesn't matter much since it's just a comment; I was just in too much of a hurry it looks like. Not sure why the comment is even there, deleting it seems cleaner.
This was referenced Sep 2, 2026
2 tasks
rgommers
added a commit
to rgommers/numpy
that referenced
this pull request
Sep 8, 2026
Since numpygh-31389, npy_common.h exempted __INTEL_LLVM_COMPILER from the branch using the MSVC runtime's _Fcomplex/_Dcomplex/_Lcomplex, so npy_cdouble became `double _Complex` for icx on Windows. The accessors in npy_math.h still call the runtime's creal()/cimag() though, and those are declared as taking _Dcomplex & co. regardless of which front end compiles them - it is the same C runtime. The two headers disagreed, so `#include <numpy/npy_math.h>` on its own stopped compiling with icx, which broke downstream builds of mkl_umath. Which complex types exist is a property of the C runtime, not of the compiler front end, so drop the exemption. That restores the 2.4.4 behaviour, which is known to build with icx. The two spellings are layout-compatible, so extensions that only use these types to describe array data were unaffected beyond the compile error. For extensions linking npymath it also changed the signature of every function there taking or returning a complex value by value; npymath is shipped as a static library, built with MSVC for the official wheels.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
With these changes, downstream users wanting to use the Intel compilers can do so when linking against NumPy headers.
Also include a build change for NumPy itself that is clearly correct: Intel compilers do not use
_Fcomplex& co for complex types, but the regular C99 complex.h types.Taken over from PR gh-25044
Closes gh-25044
Closes gh-31337 (reports the same
_Fcomplexissue)Note: I decided to start fresh because gh-25044 accumulated a conflict, and while most of that PR should no longer be relevant, I didn't want to just push a commit to remove that code. This is the most important and the clearly correct part of that PR, and there's no reason that wasn't merged already.
AI Disclosure
No AI usage