[Bug c++/60512] New: would be useful if gcc implemented __has_feature similary to clang

[Bug c++/60512] New: would be useful if gcc implemented __has_feature similary to clang

[eteran at alum dot rit.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512

            Bug ID: 60512
           Summary: would be useful if gcc implemented __has_feature
                    similary to clang
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: eteran at alum dot rit.edu

I was recently thinking about how GCC sets __cplusplus to 201103L when
-std=c++11 yet doesn't (and may not ever) fully support every single corner
case of c++11.

I agree with the notion that __cplusplus == 201103L is a statement of intent,
not 100% conformance. But how should developers write code that attempts to use
features which aren't necessarily implemented yet, but may be in the near
future or other compilers.

It occurred to me that the ideal solution may not be to test __cplusplus at
all, but instead to test for specific features. I find that that clang's
approach to this seems to hit the sweet spot. I'm sure the GCC folk are aware
of the feature, but I'll reiterate for reference. In clang:

"[This] function-like macro take a single identifier argument that is the name
of a feature. __has_feature evaluates to 1 if the feature is both supported by
Clang and standardized in the current language standard or 0 if not"

So while GCC doesn't support C++11 attributes yet, we could still code for it
today wrapping it like so.

    #if __has_feature(cxx_attributes)
    #endif

if it also supported the __has_feature (and family) suite of macros. Perhaps
this macro is mostly of interest to library writers and not a huge deal to most
developers, but I believe that it would be a tool that is *very* useful when it
turns out that you do need it.

[Bug c++/60512] would be useful if gcc implemented __has_feature similary to clang

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512

--- Comment #1 from Marc Glisse <glisse at gcc dot gnu.org> ---
http://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations

[Bug c++/60512] would be useful if gcc implemented __has_feature similary to clang

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>So while GCC doesn't support C++11 attributes yet

Wrong, it does support them, in fact for a while now.

[Bug c++/60512] would be useful if gcc implemented __has_feature similary to clang

[eteran at alum dot rit.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512

--- Comment #3 from Evan Teran <eteran at alum dot rit.edu> ---
@Andrew,

I hadn't seen that they were supported, I stand corrected. However that
particular feature was for example purposes. Any unsupported feature would do.

@Marc,

A quick read of that page shows a pretty good solution. Has any word towards
implementing its recommendations been done?

Thanks for the *very* quick response.

[Bug c++/60512] would be useful if gcc implemented __has_feature similary to clang

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512

--- Comment #4 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Evan Teran from comment #3)
> Any unsupported feature would do.

All the core features are at least partially supported, only some ABI-breaking
library changes have been postponed.

> A quick read of that page shows a pretty good solution. Has any word towards
> implementing its recommendations been done?

I don't think so. Feel free to start. Defining a bunch of macros seems like a
nice and easy way to start contributing to gcc ;-)

[Bug c++/60512] would be useful if gcc implemented __has_feature similary to clang

[acoplan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512

Alex Coplan <acoplan at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |acoplan at gcc dot gnu.org

--- Comment #9 from Alex Coplan <acoplan at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to Manuel López-Ibáñez from comment #5)
> > AFAIU, it will be welcome if someone implements it.
> 
> I see no need to add __has_feature given that it contradicts the
> recommendations of the C++ committee, and that GCC already defines the
> recommended feature test macros that can be used without __has_feature.

I think it's worth noting that __has_feature can be used to check for more than
just C++ language features. To quote the clang documentation
(https://clang.llvm.org/docs/LanguageExtensions.html):

> Another use of __has_feature is to check for compiler features not related to the language standard, such as e.g. AddressSanitizer.

LLVM users can check whether ASan is enabled using
__has_feature(address_sanitizer). Similarly one can query e.g.
__has_feature(thread_sanitizer).

I think it would be good for the alignment between GCC and LLVM if GCC were to
implement this extension.

[Bug c++/60512] would be useful if gcc implemented __has_feature similary to clang

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512

--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> ---
But why is that better than GCC's alternative, just defining macros like
__SANITIZE_ADDRESS__ and __SANITIZE_THREAD__?

Libstdc++ does this:

// Macro indicating that TSAN is in use.
#if __SANITIZE_THREAD__
#  define _GLIBCXX_TSAN 1
#elif defined __has_feature
# if __has_feature(thread_sanitizer)
#  define _GLIBCXX_TSAN 1
# endif
#endif

ISTM that it would be simpler if clang defined those macros too, because
checking for both __has_feature and then using __has_feature takes more work
than just checking a macro.

There's currently no macro for UBsan AFAIK, but one could be added.

[Bug c++/60512] would be useful if gcc implemented __has_feature similary to clang

[jrtc27 at jrtc27 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512

Jessica Clarke <jrtc27 at jrtc27 dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jrtc27 at jrtc27 dot com

--- Comment #11 from Jessica Clarke <jrtc27 at jrtc27 dot com> ---
Macros and __has_feature are equally expressive, sure, but why should Clang
change what it’s been doing from the start because GCC doesn’t want to be
compatible with how it’s always done it? It seems a bit rude to expect Clang to
change when it was the one to define how these worked first and GCC took its
implementation. It’s not like it’s a complicated thing for GCC to implement,
and it should really have done so when it added sanitizer support in order to
be fully compatible rather than do things differently and force users to
support both ways in their code (which, to this day, isn’t reliably done, so
there is code out there that only works with Clang’s sanitizers).

[Bug c++/60512] would be useful if gcc implemented __has_feature similary to clang

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WORKSFORME                  |---
                 CC|                            |jason at gcc dot gnu.org
             Status|RESOLVED                    |NEW

--- Comment #12 from Jason Merrill <jason at gcc dot gnu.org> ---
I agree that __has_feature seems redundant with feature test macros, but it
does seem reasonable to implement for portability.

[Bug c++/60512] would be useful if gcc implemented __has_feature similary to clang

[acoplan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512

--- Comment #13 from Alex Coplan <acoplan at gcc dot gnu.org> ---
Clang recognizes the "cxx_defaulted_functions" feature to detect whether "=
default" functions are supported.

It's clear that __has_feature (cxx_defaulted_functions) should evaluate to 1
for -std=c++11 and above. It's less clear whether GCC intends to support "=
default" functions in C++98 mode as an extension, and therefore whether
__has_extension (cxx_defaulted_functions) should evaluate to 1 with -std=c++98.

I noticed that e.g. we accept:

struct S {
    int x;
    S(int a) : x(a) {}
    S() = default;
};
void f() {
    S s;
}

with -std=c++98 and emit a -Wc++11-extensions warning. This suggests that "=
default" might be supported as an extension, but it's not clear. By contrast,
it seems that deleted functions (detected with "cxx_deleted_functions") aren't
supported in C++98 mode, since e.g.

struct S {
    S() = delete;
};
void f() {
    S s;
}

doesn't get rejected with -std=c++98. It would be good to get some input from
C++ maintainers on the cxx_defaulted_functions case.

[Bug c++/60512] would be useful if gcc implemented __has_feature similary to clang

[acoplan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512

Alex Coplan <acoplan at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |acoplan at gcc dot gnu.org

--- Comment #14 from Alex Coplan <acoplan at gcc dot gnu.org> ---
I'm working on this.

[Bug c++/60512] would be useful if gcc implemented __has_feature similary to clang

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512

--- Comment #15 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Alex Coplan from comment #14)
> I'm working on this.

I will rebase my WIP and push it somewhere - [ it has __has_feature and
__has_extension components .. but likely bit rotten with changes to libcpp ]
(sorry for being slow to do this - releases tie up all my Darwin time.

[Bug c++/60512] would be useful if gcc implemented __has_feature similary to clang

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512

--- Comment #16 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #15)
> (In reply to Alex Coplan from comment #14)
> > I'm working on this.
> 
> I will rebase my WIP and push it somewhere - [ it has __has_feature and
> __has_extension components .. but likely bit rotten with changes to libcpp ]
> (sorry for being slow to do this - releases tie up all my Darwin time.

https://github.com/iains/gcc-git/tree/master-wip-has-extension

(it might not even build - I was hoping to have some time to refresh it - but
better publish now in case it's useful in any way )

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)

[Bug c++/60512] would be useful if gcc implemented __has_feature similary to clang

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512

--- Comment #17 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #16)
> (In reply to Iain Sandoe from comment #15)
> > (In reply to Alex Coplan from comment #14)
> > > I'm working on this.
> > 
> > I will rebase my WIP and push it somewhere - [ it has __has_feature and
> > __has_extension components .. but likely bit rotten with changes to libcpp ]
> > (sorry for being slow to do this - releases tie up all my Darwin time.
> 
> https://github.com/iains/gcc-git/tree/master-wip-has-extension
> 
> (it might not even build - I was hoping to have some time to refresh it -
> but better publish now in case it's useful in any way )

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.

[Bug c++/60512] would be useful if gcc implemented __has_feature similarly to clang

[acoplan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512

--- Comment #18 from Alex Coplan <acoplan at gcc dot gnu.org> ---
(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.

[Bug c++/60512] would be useful if gcc implemented __has_feature similarly to clang

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512

--- Comment #19 from Iain Sandoe <iains at gcc dot gnu.org> ---
(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

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512

--- Comment #20 from Iain Sandoe <iains at gcc dot gnu.org> ---
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

[acoplan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512

--- Comment #21 from Alex Coplan <acoplan at gcc dot gnu.org> ---
(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

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512

--- Comment #22 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Alex Coplan <acoplan@gcc.gnu.org>:

https://gcc.gnu.org/g:06280a906cb3dc80cf5e07cf3335b758848d488d

commit r14-5873-g06280a906cb3dc80cf5e07cf3335b758848d488d
Author: Alex Coplan <alex.coplan@arm.com>
Date:   Fri Mar 17 16:30:51 2023 +0000

    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 <iain@sandoe.co.uk>

[Bug c++/60512] would be useful if gcc implemented __has_feature similarly to clang

[acoplan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512

Alex Coplan <acoplan at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #23 from Alex Coplan <acoplan at gcc dot gnu.org> ---
Implemented for GCC 14.

[Bug c++/60512] would be useful if gcc implemented __has_feature similarly to clang

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |egallager at gcc dot gnu.org

--- Comment #24 from Eric Gallager <egallager at gcc dot gnu.org> ---
(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?