[Bug libstdc++/101055] New: should use __has_cpp_attribute() with __ prefixed/suffixed names

[Bug libstdc++/101055] New: should use __has_cpp_attribute() with __ prefixed/suffixed names

[rguenth at gcc dot gnu.org]

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

            Bug ID: 101055
           Summary: should use __has_cpp_attribute() with __
                    prefixed/suffixed names
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

For example in <tuple> we see

#if __has_cpp_attribute(no_unique_address)

but then we use

      [[__no_unique_address__]] _Head _M_head_impl;

presumably to not cause issues with user-defined macros.  But the
__has_cpp_attribute check is also subject to macro expansion so we should
use the __X__ form consistently.

This seems to be the only use of __has_cpp_attribute in libstdc++.

[Bug libstdc++/101055] should use __has_cpp_attribute() with __ prefixed/suffixed names

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2021-06-14
     Ever confirmed|0                           |1

[Bug libstdc++/101055] [11/12 Regression] should use __has_cpp_attribute() with __ prefixed/suffixed names

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |10.3.0
            Summary|should use                  |[11/12 Regression] should
                   |__has_cpp_attribute() with  |use __has_cpp_attribute()
                   |__ prefixed/suffixed names  |with __ prefixed/suffixed
                   |                            |names
      Known to fail|                            |11.1.0, 12.0

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
This is a regression, because this should be valid in C++11/14/17 (but not
C++20)

#define no_unique_address 1
#include <tuple>

[Bug libstdc++/101055] [11/12 Regression] should use __has_cpp_attribute() with __ prefixed/suffixed names

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.2

[Bug libstdc++/101055] [11/12 Regression] should use __has_cpp_attribute() with __ prefixed/suffixed names

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Regressed with r11-2720-g91e6226f880b048275a7ceedef716e159c7cefd9
and r11-4074-gfc77484c4a4feb308c64371233cb65b280333953 started using __ __ in
the attribute but not in __has_cpp_attribute.

[Bug libstdc++/101055] [11/12 Regression] should use __has_cpp_attribute() with __ prefixed/suffixed names

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:917efba2dd4ff34336d0d3aa55285ae22503e4aa

commit r12-1420-g917efba2dd4ff34336d0d3aa55285ae22503e4aa
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Mon Jun 14 10:58:15 2021 +0100

    libstdc++: Use reserved name for attribute [PR101055]

    The no_unique_address attribute is not a reserved name until C++20, so
    to use it in C++11/14/17 modes we should use the __no_unique_address_
    form. We already use that form when using the attribute, but not in the
    __has_cpp_attribute check.

    libstdc++-v3/ChangeLog:

            PR libstdc++/101055
            * include/std/tuple: Use reserved form of attribute name.
            * testsuite/17_intro/headers/c++2011/all_attributes.cc: Add
            check for no_unique_address.
            * testsuite/17_intro/headers/c++2014/all_attributes.cc:
            Likewise.
            * testsuite/17_intro/headers/c++2017/all_attributes.cc:
            Likewise.

[Bug libstdc++/101055] [11/12 Regression] should use __has_cpp_attribute() with __ prefixed/suffixed names

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
<redi@gcc.gnu.org>:

https://gcc.gnu.org/g:c4f1bbed3d0184955d39adf0be287667891baf83

commit r11-8567-gc4f1bbed3d0184955d39adf0be287667891baf83
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Mon Jun 14 10:58:15 2021 +0100

    libstdc++: Use reserved name for attribute [PR101055]

    The no_unique_address attribute is not a reserved name until C++20, so
    to use it in C++11/14/17 modes we should use the __no_unique_address_
    form. We already use that form when using the attribute, but not in the
    __has_cpp_attribute check.

    libstdc++-v3/ChangeLog:

            PR libstdc++/101055
            * include/std/tuple: Use reserved form of attribute name.
            * testsuite/17_intro/headers/c++2011/all_attributes.cc: Add
            check for no_unique_address.
            * testsuite/17_intro/headers/c++2014/all_attributes.cc:
            Likewise.
            * testsuite/17_intro/headers/c++2017/all_attributes.cc:
            Likewise.

    (cherry picked from commit 917efba2dd4ff34336d0d3aa55285ae22503e4aa)

[Bug libstdc++/101055] [11/12 Regression] should use __has_cpp_attribute() with __ prefixed/suffixed names

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

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

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed for 11.2

[Bug libstdc++/101055] [11/12 Regression] should use __has_cpp_attribute() with __ prefixed/suffixed names

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |http://bugzilla.opensuse.or
                   |                            |g/show_bug.cgi?id=1187254

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
N.B. this fixes a problem when using libstdc++ 11.1 headers with Clang 9, where
the __has_cpp_attribute(no_unique_address) test was true, but the
[[__no_unique_address__]] attribute was not recognized and so was ignored,
resulting in layout changes for std::tuple.

[Bug libstdc++/101055] [11/12 Regression] should use __has_cpp_attribute() with __ prefixed/suffixed names

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I think this also affects the Intel compiler, as the latest release doesn't
handle [[__no_unique_address__]].