[PATCH] c++/objective-c++; Do not claim feature(modules), it is clang-specific.

Iain Sandoe <[email protected]> Tue, 4 Aug 2026 09:56:30 +0100
Newsgroups gmane.comp.gcc.patches
Message-ID <[email protected]>
Tested on x86_64 darwin24 where we now correctly create the std module
sources and gcms.  OK for trunk and relevant backports? thanks,
Iain

--- 8< ---

It appears that we misinterpreted the modules feature and that it is intended
to signal that the compiler supports "clang modules".  These are a similar
approach to PCH and tightly coupled to clang AST - so not something that we
are realistically likely to implement.

Unfortunately, the macOS SDKs use this feature test to decide on some
header declaration ordering where it needs to change for clang modules.

This causes a fail to build the std. module sources on macOS meaning that we
get an empty std.cc. Our intention should be parity with/without -fmodules.

The solution is not to claim feature(modules) - C++20 modules are gated on
__cpp_module and so do not need it.

gcc/cp/ChangeLog:

	* cp-objcp-common.cc: Remove claim to support clang modules.

Signed-off-by: Iain Sandoe <[email protected]>
---
 gcc/cp/cp-objcp-common.cc | 1 -
 1 file changed, 1 deletion(-)

diff --git a/gcc/cp/cp-objcp-common.cc b/gcc/cp/cp-objcp-common.cc
index 0a67aa8ce14..8c9930bb2f3 100644
--- a/gcc/cp/cp-objcp-common.cc
+++ b/gcc/cp/cp-objcp-common.cc
@@ -148,7 +148,6 @@ static constexpr cp_feature_info cp_feature_table[] =
   { "cxx_relaxed_constexpr", cxx14 },
   { "cxx_return_type_deduction", cxx14 },
   { "cxx_variable_templates", cxx14 },
-  { "modules", &flag_modules },
 };
 
 /* Register C++ language features for __has_{feature,extension}.  */
-- 
2.50.1 (Apple Git-155)