numeric_limits.hpp error: "constexpr" is not valid here constexpr int min_exponent = std::numeric_limits<int>::min_exponent;

[jrobcary]

Compiling code with clang-cl from LLVM20. Code has cmake build system, compiled with C++17 standard.

Tons of errors like

D:\winsame\cary\dev1\contrib-llvm20_vs2022\boost-1_90.0-ser\include\boost/math/tools/numeric_limits.hpp(91): error: "constexpr" is not valid here
constexpr bool is_signed = std::numeric_limits::is_signed;

D:\winsame\cary\dev1\contrib-llvm20_vs2022\boost-1_90.0-ser\include\boost/math/tools/numeric_limits.hpp(92): error: "constexpr" is not valid here
constexpr bool is_integer = std::numeric_limits::is_integer;

A typical offending line:
BOOST_MATH_STATIC bool is_signed = std::numeric_limits<double>::is_signed;

It looks like this is coming from config.hpp:

#  ifndef BOOST_MATH_HAS_GPU_SUPPORT
#    define BOOST_MATH_INLINE_CONSTEXPR static constexpr
#    define BOOST_MATH_STATIC static
#    define BOOST_MATH_STATIC_LOCAL_VARIABLE
#  else
#    define BOOST_MATH_INLINE_CONSTEXPR constexpr.
#    define BOOST_MATH_STATIC constexpr <-------

I tried changing constexpr to static, but the code still fails to compile.

Is there a better way to deal with this?
Disable GPU in Boost?

[jrobcary]

This patch gets my code to compile.

diff -ruN boost-1_90.0/boost/math/tools/config.hpp boost-1_90.0-new/boost/math/tools/config.hpp
--- boost-1_90.0/boost/math/tools/config.hpp    2025-12-03 06:46:43.000000000 -0700
+++ boost-1_90.0-new/boost/math/tools/config.hpp        2026-03-28 10:59:57.577160600 -0600
@@ -674,7 +674,8 @@
 // CUDA support:
 //

-#ifdef __CUDACC__
+// #ifdef __CUDACC__
+#if 0

 // We have to get our include order correct otherwise you get compilation failures
 #include <cuda.h>

[jzmaddock]

Is there a better way to deal with this?
Disable GPU in Boost?

Well... I assume that you are seeing this because you are compiling for GPU: if that's not the case then something has gone very wrong somewhere and/or you have some stray defines set.

But assuming everything else is good, then it looks like we might need to take the BOOST_MATH_HAS_NVRTC branch for this GPU "flavour", and we might need some more info to allow us to select it.

@mborland ?

[jrobcary]

Yes, using nvcc, but my code does not make use of any boost-gpu constructs, so I was hoping to be able to disable them, as they give the noted compile error.

I'll be glad to provide any info and/or test proposed solutions.

[jzmaddock]

I think there may be a few workarounds you could try (without having to modify the source), also a couple of likely bugs on our side.

@jrobcary #1, from what I can read of our config, if __cpp_inline_variables is set then this issue shouldn't arise, am I correct that your compiler is not setting this even in C++17 mode? What about in C++20, or if you manually include <version> before boost?
@jrobcary #2, as a last ditch workaround, you could isolating boost usage in non-GPU compiled .cpp files, but I appreciate that may be a right hassle.

@mborland #1, Looking at out config, I think this line

math/include/boost/math/tools/config.hpp

Line 777 in cfe946f

# define BOOST_MATH_STATIC constexpr

is erroneous: since a constexpr class data member must be static or else we absolutely will get a compiler error. Further, when __cpp_inline_variables is set we do always set BOOST_MATH_STATIC to static, so I see no reason not to do when it's not set also?
@mborland #2: I wonder if we are being too greedy in marking up GPU support, the OP is using Boost in a CUDA compiled source file, but not on the GPU and so doesn't need the markup here. But maybe I'm being too optimistic? ;)

[mborland]

I'll take a look this morning @jzmaddock. The NVRTC case has tons of weirdness but none of that should be hit here. The user has to set a CMake flag to enable CUDA modes but it looks like that flag isn't being checked in all places, so yes we're much greedier than we should be.

[jrobcary]

@jzmaddock , I am using clang-cl from LLVM20. This is a cmake project, and I have set
-DCMAKE_CXX_STANDARD:STRING='17'
I can try putting <version> above boost later today if still desired.

[mborland]

This should be fixed by the linked PR #1384. @jrobcary there are 2 .cu files in that PR that contain various tests. Can you try them both with your environment and see if your issue is fixed? I ran them on Ubuntu 24.04 with GCC 13.4.0 as the host compiler and CUDA toolkit v13.1. Our CI system is similar, but uses CUDA toolkit v12.8