[Bug libstdc++/115480] New: Difference between trivial copyability of std::pair under Clang in C++23

[Bug libstdc++/115480] New: Difference between trivial copyability of std::pair under Clang in C++23

[ldionne.2 at gmail dot com]

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

            Bug ID: 115480
           Summary: Difference between trivial copyability of std::pair
                    under Clang in C++23
           Product: gcc
           Version: 15.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ldionne.2 at gmail dot com
  Target Milestone: ---

Let's say Foo is a trivially copyable type without an assignment operator.

In C++23, std::pair<Foo, int> is currently trivially copyable using Clang trunk
and GCC trunk. However, it wasn't trivially copyable in the Clang 15 era.

Godbolt: https://godbolt.org/z/TKK7qhhbM

I don't know whether y'all care about this, but we ran into this while
investigating some libc++ stuff and we thought we'd point it out in case it was
considered an ABI break introduced ~2 years ago.

[Bug c++/115480] Difference between trivial copyability of std::pair under Clang in C++23

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---

  template<typename _Tp>
    struct is_trivially_copyable
    : public integral_constant<bool, __is_trivially_copyable(_Tp)>


Well it is clang front-end issue though it looks like GCC had a similar issue
too.

[Bug c++/115480] Difference between trivial copyability of std::pair under Clang in C++23

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
#include <type_traits>
#include <utility>

struct trivially_copyable_no_assignment {
  int arr[4];
  trivially_copyable_no_assignment& operator=(const
trivially_copyable_no_assignment&) = delete;
};

static_assert(std::is_trivially_copyable<std::pair<trivially_copyable_no_assignment,
int> >::value, "");

int main() { }

[Bug c++/115480] Difference between trivial copyability of std::pair under Clang in C++23

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WONTFIX
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Since this is a front-end issue for clang there is not much GCC/libstdc++
cannot do. Plus GCC 12.3 contained the fix that happened to be a bug in GCC 12
series so closing as won't fix.

[Bug c++/115480] Difference between trivial copyability of std::pair under Clang in C++23

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note the change for GCC 12.3.0 that fix it was r12-8799-gaeba3e009b0abf .

[Bug c++/115480] Difference between trivial copyability of std::pair under Clang in C++23

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #4)
> Note the change for GCC 12.3.0 that fix it was r12-8799-gaeba3e009b0abf .

https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602548.html

[Bug c++/115480] Difference between trivial copyability of std::pair under Clang in C++23

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Louis Dionne from comment #0)
> we thought we'd point it out in case it
> was considered an ABI break introduced ~2 years ago.

Thanks! It looks like this changed the ABI in C++20 mode, making it consistent
with the ABI in C++17 mode ... which is good (the other way around would be
more concerning). And C++20 mode isn't considered stable, so a change that only
affects C++20 mode isn't something we're going to worry about.