Description
When CMake 3.31.8 bootstraps with GCC 14.3 on an Intel CPU that enables -mavx10.1 via -march=native (Granite Rapids, future
AVX10-capable parts), the C++11 feature checks in Source/Checks/cm_cxx_features.cmake falsely report the compiler as not
supporting make_unique, unique_ptr, and filesystem — and bootstrap aborts:
CMake Error at CMakeLists.txt:93 (message):
The C++ compiler does not support C++11 (e.g. std::unique_ptr).
The compiler does support C++11; the test programs in Source/Checks/cm_cxx_make_unique.cxx etc. compile, link, and execute
correctly. The failure is in the check logic, not the compiler.
Root cause
cm_cxx_features.cmake strips a list of known benign warning lines from each check’s OUTPUT_VARIABLE, then runs a catch-all:
if(check_output MATCHES “(^|[ :])[Ww][Aa][Rr][Nn][Ii][Nn][Gg]”)
set(CMake_HAVE_CXX_${FEATURE} OFF CACHE INTERNAL “TRY_COMPILE” FORCE)
endif()
The strip list includes ninja, MSBuild, MSVC, ld, distcc, libhugetlbfs, xcodebuild, icpc, icpx, etc. — but no GCC cc1plus: filter.
On Granite Rapids with -march=native, GCC 14.3 emits on every compile:
cc1plus: warning: ‘-mavx10.1’ is aliased to 512 bit since GCC14.3
(-march=native enables -mavx10.1; GCC 14.3 added -mavx10.1 as alias for -mavx10.1-512, then warns about it.) This line passes
every filter, the catch-all matches “warning”, and the feature is marked broken.
Reproducer
Anywhere that has GCC 14.3 and an Intel CPU with AVX10 support:
tar xf cmake-3.31.8.tar.gz && cd cmake-3.31.8
export CXXFLAGS=“-O2 -march=native”
./bootstrap
fails on cm_check_cxx_feature(make_unique). CMakeFiles/CMakeError.log
under the build dir shows the cc1plus warning in each failed transcript.
(-march=native is what triggers -mavx10.1; any opt level + -march=native reproduces. EasyBuild’s default -O2 -ftree-vectorize
-march=native -fno-math-errno for GCC 14.3 is one such combination — that’s how the issue originally surfaced.)
A standalone try_compile() of the same Source/Checks/cm_cxx_make_unique.cxx from a user-written CMakeLists.txt succeeds — because
it doesn’t go through cm_check_cxx_feature. So the bug is specifically in the filter chain there.
Suggested fix
Extend the filter list in cm_check_cxx_feature to strip GCC’s -mavx10.x is aliased warning before the catch-all match. Narrow
regex so unrelated cc1plus warnings still surface:
# Filter out distcc.
string(REGEX REPLACE "[^\n]*distcc\\[[0-9]+\\][^\n]*[Ww]arning:[^\n]*" "" check_output "${check_output}")
-
Filter out GCC’s benign “-mavx10.x is aliased to N bit” cc1/cc1plus warnings.
-
string(REGEX REPLACE “[^\n]cc1[a-z]: warning: ‘-mavx10\.[0-9]+’ is aliased to[^\n]*” “” check_output “${check_output}”)
If using the feature causes warnings, treat it as broken/unavailable.
if(check_output MATCHES “(^|[ :])[Ww][Aa][Rr][Nn][Ii][Nn][Gg]”)
Verified end-to-end: with this filter, make_unique, unique_ptr, and filesystem checks pass; Configuring done; build proceeds
normally.
A broader question worth raising separately: is the catch-all “any matching warning in output = feature broken” rule the right
policy? It’s brittle by design — every new compiler/tool with a previously-unseen warning string breaks it. Maybe restrict the
rule to warnings that originate from the test source, not from the compiler/driver setup chatter. That’s a bigger change, though;
the targeted filter is enough to unblock 3.31.8+ on current Intel hardware.
Environment
- CMake 3.31.8 (3.31.3 unaffected; 4.0.3 likely affected, not yet confirmed)
- GCC 14.3.0
- Intel Xeon 6760P (Granite Rapids)
- RHEL 9.6 / Linux 5.14