BUG: Incorrect use of __GNUC__
preprocessor guards may disable features on clang
#20479
Labels
Build issues
Issues with building from source, including different choices of architecture, compilers and OS
defect
A clear bug or issue that prevents SciPy from being installed or used as expected
scipy._lib
scipy.spatial
scipy.special
In the context of #19816, we found that
While looking at bumping the GCC minimum version (#20478), I ended up stumbling over at least one place where we require
GCC >=4.4
through macros, which will disable the respective feature on clang (which defaults to GCC 4.1).scipy/scipy/_lib/src/ccallback.h
Line 69 in b76ca45
There's also many places where
__GNUC__
occurs in the boost submodule, though I haven't audited them all for correctness (and many of them do correctly add|| defined(__clang__)
or|| __clang_major__ >= <some_major_ver>
).I propose that we add explicit guards like boost does (and simplify our logic to avoid
__GNUC_MINOR__
, since our minimum supported version is far beyond 4.x anyway). Other places that only check whether__GNUC__
is defined should be OK, as clang will set it by default, though we could be more explicit there as well.Finally, a separate mention for places that intentionally avoid clang. I'm quite sure that in these cases, similar functionality exists on clang as well, and we should enable the same optimizations there as well:
scipy/scipy/special/cephes/mconf.h
Lines 91 to 98 in b76ca45
scipy/scipy/spatial/src/distance_wrap.c
Lines 35 to 44 in b76ca45
The text was updated successfully, but these errors were encountered: