# cm\_cxx\_features.cmake warning filter misses cc1plus "-mavx10.1" warning, breaks bootstrap on Intel Granite Rapids with GCC 14.3

**URL:** https://discourse.cmake.org/t/cm-cxx-features-cmake-warning-filter-misses-cc1plus-mavx10-1-warning-breaks-bootstrap-on-intel-granite-rapids-with-gcc-14-3/15660
**Category:** Development
**Created:** [May 22, 2026, 2:20pm UTC](https://discourse.cmake.org/t/cm-cxx-features-cmake-warning-filter-misses-cc1plus-mavx10-1-warning-breaks-bootstrap-on-intel-granite-rapids-with-gcc-14-3/15660 "2026-05-22T14:20:04Z")
**Posts on this page:** 2
**Page:** 1

<div class="post-metadata">

### Author: ![ejames604](https://discourse.cmake.org/user_avatar/discourse.cmake.org/ejames604/32/6135_2.png) [@ejames604](https://discourse.cmake.org/u/ejames604)
#### Post date: [May 22, 2026, 2:20pm UTC](https://discourse.cmake.org/t/cm-cxx-features-cmake-warning-filter-misses-cc1plus-mavx10-1-warning-breaks-bootstrap-on-intel-granite-rapids-with-gcc-14-3/15660/1 "2026-05-22T14:20:05Z")

</div>

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:

```auto
   # 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}”)

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

---

<div class="post-metadata">

### Author: ![brad.king](https://discourse.cmake.org/user_avatar/discourse.cmake.org/brad.king/32/11_2.png) [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [May 27, 2026, 2:08pm UTC](https://discourse.cmake.org/t/cm-cxx-features-cmake-warning-filter-misses-cc1plus-mavx10-1-warning-breaks-bootstrap-on-intel-granite-rapids-with-gcc-14-3/15660/2 "2026-05-27T14:08:26Z")

</div>

See [CMake MR 11943](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/11943/diffs). It was included in CMake 4.3.2.

> every new compiler/tool with a previously-unseen warning string breaks it.

We cannot know ahead of time whether a given string indicates a lack of support for what’s being checked. It’s better to fail and fix a false positive than to have a false negative.

> not from the compiler/driver setup chatter

IMO a compiler that warns about its own setup is broken and doesn’t need to be supported except by special cases.