[Bug c++/60512] would be useful if gcc implemented __has_feature similarly to clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #24 from Eric Gallager --- (In reply to Alex Coplan from comment #23) > Implemented for GCC 14. Thanks! Could you add a note to gcc-14/changes.html in gcc-wwwdocs so that people can be aware of it?
[Bug c++/60512] would be useful if gcc implemented __has_feature similarly to clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512 Alex Coplan changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #23 from Alex Coplan --- Implemented for GCC 14.
[Bug c++/60512] would be useful if gcc implemented __has_feature similarly to clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512
--- Comment #22 from GCC Commits ---
The master branch has been updated by Alex Coplan :
https://gcc.gnu.org/g:06280a906cb3dc80cf5e07cf3335b758848d488d
commit r14-5873-g06280a906cb3dc80cf5e07cf3335b758848d488d
Author: Alex Coplan
Date: Fri Mar 17 16:30:51 2023 +
c-family: Implement __has_feature and __has_extension [PR60512]
This patch implements clang's __has_feature and __has_extension in GCC.
Currently the patch aims to implement all documented features (and some
undocumented ones) following the documentation at
https://clang.llvm.org/docs/LanguageExtensions.html with the exception
of the legacy features for C++ type traits. These are omitted, since as
the clang documentation notes, __has_builtin is the correct "modern" way
to query for these (which GCC already implements).
gcc/c-family/ChangeLog:
PR c++/60512
* c-common.cc (struct hf_feature_info): New.
(c_common_register_feature): New.
(init_has_feature): New.
(has_feature_p): New.
* c-common.h (c_common_has_feature): New.
(c_family_register_lang_features): New.
(c_common_register_feature): New.
(has_feature_p): New.
* c-lex.cc (init_c_lex): Plumb through has_feature callback.
(c_common_has_builtin): Generalize and move common part ...
(c_common_lex_availability_macro): ... here.
(c_common_has_feature): New.
* c-ppoutput.cc (init_pp_output): Plumb through has_feature.
gcc/c/ChangeLog:
PR c++/60512
* c-lang.cc (c_family_register_lang_features): New.
* c-objc-common.cc (struct c_feature_info): New.
(c_register_features): New.
* c-objc-common.h (c_register_features): New.
gcc/cp/ChangeLog:
PR c++/60512
* cp-lang.cc (c_family_register_lang_features): New.
* cp-objcp-common.cc (struct cp_feature_selector): New.
(cp_feature_selector::has_feature): New.
(struct cp_feature_info): New.
(cp_register_features): New.
* cp-objcp-common.h (cp_register_features): New.
gcc/ChangeLog:
PR c++/60512
* doc/cpp.texi: Document __has_{feature,extension}.
gcc/objc/ChangeLog:
PR c++/60512
* objc-act.cc (struct objc_feature_info): New.
(objc_nonfragile_abi_p): New.
(objc_common_register_features): New.
* objc-act.h (objc_common_register_features): New.
* objc-lang.cc (c_family_register_lang_features): New.
gcc/objcp/ChangeLog:
PR c++/60512
* objcp-lang.cc (c_family_register_lang_features): New.
libcpp/ChangeLog:
PR c++/60512
* include/cpplib.h (struct cpp_callbacks): Add has_feature.
(enum cpp_builtin_type): Add BT_HAS_{FEATURE,EXTENSION}.
* init.cc: Add __has_{feature,extension}.
* macro.cc (_cpp_builtin_macro_text): Handle
BT_HAS_{FEATURE,EXTENSION}.
gcc/testsuite/ChangeLog:
PR c++/60512
* c-c++-common/has-feature-common.c: New test.
* c-c++-common/has-feature-pedantic.c: New test.
* g++.dg/ext/has-feature.C: New test.
* gcc.dg/asan/has-feature-asan.c: New test.
* gcc.dg/has-feature.c: New test.
* gcc.dg/ubsan/has-feature-ubsan.c: New test.
* obj-c++.dg/has-feature.mm: New test.
* objc.dg/has-feature.m: New test.
Co-Authored-By: Iain Sandoe
[Bug c++/60512] would be useful if gcc implemented __has_feature similarly to clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512 --- Comment #21 from Alex Coplan --- (In reply to Iain Sandoe from comment #17) > > heh, despite that I've not done anything to it since 2019 actually it builds > and the tests pass - at least for C. Anyway, see what you think and how it > lines up with your intended impl. Thanks. I've posted what I came up with so far as an RFC here: https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617878.html
[Bug c++/60512] would be useful if gcc implemented __has_feature similarly to clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512 --- Comment #20 from Iain Sandoe --- although, I guess, we could have one table and somehow include the target in predicates if appropriate...
[Bug c++/60512] would be useful if gcc implemented __has_feature similarly to clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512 --- Comment #19 from Iain Sandoe --- (In reply to Alex Coplan from comment #18) > (In reply to Iain Sandoe from comment #16) > > > > AFAIR the main blocker to progress was trying to decide how to represent the > > target/language/language version dependencies of the features and extensions > > (there's a rudimentary scheme at the moment but it probably is not flexible > > enough) > > Can you elaborate on this a little? In particular I'd be interested to hear > about cases where the target matters. the first commit in my WIP branch is "generic support" (i.e. features that are [intended to be] common to all targets) the second commit identifies a set of features that (I would want to be) supported on Darwin, but maybe not relevant to other targets. Of course, we hope the first set to be the largest. Targets like Darwin and Windows are more likely to need such things - where compatibility with external ABI and system tools means we're trying to comply with design decisions out of our control. However, it is presumably conceivable that (say) variable length vector features could be relevant to aarch64 and risc-v but not elsewhere (I'm speculating here, so no concrete example or evidence).
[Bug c++/60512] would be useful if gcc implemented __has_feature similarly to clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512 --- Comment #18 from Alex Coplan --- (In reply to Iain Sandoe from comment #16) > > AFAIR the main blocker to progress was trying to decide how to represent the > target/language/language version dependencies of the features and extensions > (there's a rudimentary scheme at the moment but it probably is not flexible > enough) Can you elaborate on this a little? In particular I'd be interested to hear about cases where the target matters.
