On 6/28/23 06:35, Alex Coplan wrote:
Hi,
This patch implements clang's __has_feature and __has_extension in GCC.
This is a v2 of the original RFC posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617878.html
Changes since v1:
- Follow the clang behaviour where -pedantic-errors means that
__has_extension behaves exactly like __has_feature.
- We're now more conservative with reporting C++ features as extensions
available in C++98. For features where we issue a pedwarn in C++98
mode, we no longer report these as available extensions for C++98.
- Switch to using a hash_map to store the features. As well as ensuring
lookup is constant time, this allows us to dynamically register
features (right now based on frontend, but later we could allow the
target to register additional features).
- Also implement some Objective-C features, add a langhook to dispatch
to each frontend to allow it to register language-specific features.
Hmm, it seems questionable to use a generic langhook for something that
the generic code doesn't care about, only the c-family front ends. A
common pattern in c-family is to declare a signature in c-common.h and
define it differently for the various front-ends, i.e. in the *-lang.cc
files.
There is an outstanding question around what to do with
cxx_binary_literals in the C frontend for C2x. Should we introduce a new
c_binary_literals feature that is a feature in C2x and an extension
below that, or should we just continue using the cxx_binary_literals
feature and mark that as a standard feature in C2x? See the comment in
c_feature_table in the patch.
What does clang do here?
There is also some doubt over what to do with the undocumented "tls"
feature. In clang this is gated on whether the target supports TLS, but
in clang (unlike GCC) it is a hard error to use TLS when the target
doesn't support it. In GCC I believe you can always use TLS, you just
get emulated TLS in the case that the target doesn't support it
natively. So in this patch GCC always reports having the "tls" feature.
Would appreciate if anyone has feedback on this aspect.
Hmm, I don't think GCC always supports TLS, given that the testsuite has
a predicate to check for that support (and others to check for emulated
or native support).
But I think it's right to report having "tls" for emulated support.
I know Iain was concerned that it should be possible to have
target-specific features. Hopefully it is clear that the design in this
patch is more amenable in this. I think for Darwin it should be possible
to add a targetcm hook to register additional features (either passing
through a callback to allow the target code to add to the hash_map, or
exposing a separate langhook that the target can call to register
features).
The design seems a bit complicated still, with putting a callback into
the map. Do we need the callbacks? Do we expect the value of
__has_feature to change at different points in compilation? Does that
happen in clang?
Bootstrapped/regtested on aarch64-linux-gnu and x86_64-apple-darwin. Any
thoughts?
Most of the patch needs more comments, particularly before various
top-level definitions.
Jason
