On 8/3/23 05:21, Alex Coplan wrote:
Hi,
This patch implements clang's __has_feature and __has_extension in GCC.
This is a v3 which addresses feedback for the v2 patch posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626058.html
Main changes since v2:
- As per Jason's feedback, dropped the langhook in favour of
a function prototyped in c-family/c-common.h and implemented in
*-lang.cc for each frontend.
- Also dropped the callbacks as suggested, we now compute whether
features/extensions are available when __has_feature is first invoked,
and only add available features to the hash table (storing a boolean
to indicate whether a given identifier names a feature or an extension).
- Added many comments to top-level definitions.
- Generally polished and tidied up a bit.
As of this writing, there are still a couple of unresolved issues
around cxx_binary_literals and TLS, see:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626058.html
I think what you have for these makes sense.
Bootstrapped/regtested on aarch64-linux-gnu and x86_64-apple-darwin.
How does this version look?
diff --git a/gcc/doc/cpp.texi b/gcc/doc/cpp.texi
index 3f492b33470..76dbb9892d6 100644
--- a/gcc/doc/cpp.texi
+++ b/gcc/doc/cpp.texi
@@ -3199,6 +3199,8 @@ directive}: @samp{#if}, @samp{#ifdef} or @samp{#ifndef}.
* @code{__has_cpp_attribute}::
* @code{__has_c_attribute}::
* @code{__has_builtin}::
+* @code{__has_feature}::
+* @code{__has_extension}::
* @code{__has_include}::
@end menu
@@ -3561,6 +3563,33 @@ the operator is as follows:
#endif
@end smallexample
+@node @code{__has_feature}
+@subsection @code{__has_feature}
+@cindex @code{__has_feature}
+
+The special operator @code{__has_feature (@var{operand})} may be used in
+constant integer contexts and in preprocessor @samp{#if} and @samp{#elif}
+expressions to test whether the identifier given in @var{operand} is recognized
+as a feature supported by GCC given the current options and, in the case of
+standard language features, whether the feature is available in the chosen
+version of the language standard.
+
+@node @code{__has_extension}
+@subsection @code{__has_extension}
+@cindex @code{__has_extension}
+
+The special operator @code{__has_extension (@var{operand})} may be used in
+constant integer contexts and in preprocessor @samp{#if} and @samp{#elif}
+expressions to test whether the identifier given in @var{operand} is recognized
+as an extension supported by GCC given the current options. In any given
+context, the features accepted by @code{__has_extension} are a strict superset
+of those accepted by @code{__has_feature}. Unlike @code{__has_feature},
+@code{__has_extension} tests whether a given feature is available regardless of
+strict language standards conformance.
+
+If the @code{-pedantic-errors} flag is given, @code{__has_extension} is
+equivalent to @code{__has_feature}.
+
I think we need some documentation of what identifiers someone might
specify. It might be best to say that these are not recommended for new
code, just provided for Clang compatibility, and point to their
documentation. I notice that we already refer to Clang docs for UBSan.
Jason
