New __ptrauth types are wrongly reported as __is_bitwise_cloneable

[halbi2]

struct S1 {
  int * __ptrauth(1,1,50) p_;
};
static_assert(!__is_bitwise_cloneable(S1));

This test case fails. I apologise for missing this trait at the time that I filed #137473 and #137474.
The purpose of __is_bitwise_cloneable is not clear, libc++ does not use it, but ptrauth types are surely not bitwise copyable.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: None (halbi2)

``` struct S1 { int * __ptrauth(1,1,50) p_; }; static_assert(!__is_bitwise_cloneable(S1)); ```

This test case fails. I apologise for missing this trait at the time that I filed #137473 and #137474.
The purpose of __is_bitwise_cloneable is not clear, libc++ does not use it, but ptrauth types are surely not bitwise copyable.

[AaronBallman]

CC @ojhunt

[ojhunt]

We didn't finish the work on __trivially_relocate either, I'll use this bug for

• __is_bitwise_clonable
• __trivially_relocatable, copyable, etc, etc
• anything else I can find

@cor3ntin @AaronBallman can you think of any other intrinsics/builtins that would lie if you can't essentially memcpy an "ordinary looking" type? Or can you think of someone else who might know of some?

[ojhunt]

Behold the list I think is complete. @cor3ntin I'm unsure about a few of these - I'll look at the code if necessary, but if you happen to know off hand that would be great.

• __builtin_is_cpp_trivially_relocatable
• __is_trivially_relocatable
• __is_bitwise_cloneable
• __builtin_is_replaceable ?
• __is_trivially_copyable
• __is_trivially_assignable
• __is_trivial (what does this one mean? inquiring minds need to know!)
• __is_standard_layout (address discriminated fields in structs make them non-POD, does standard layout imply POD?)
• __is_pod (address discrimination == no)
• __has_trivial_move_assign
• __has_trivial_move_constructor
• __is_trivially_equality_comparable
• __can_pass_in_regs

[ojhunt]

As in this report __bitwise_clonable fails, but here's the full list - at least from the above list of builtins:

• __bitwise_clonable - returns true for structs with address discriminated fields, and address discriminated primitives
• __builtin_is_replaceable - returns true for structs with address discriminated fields, and address discriminated primitives
• __is_trivial returns true on address discriminated primitives
• __is_standard_layout returns true for structs with address discriminated fields and primitives, but I don't know what standard layout implies in this case
• __is_pod returns true for address discriminated primitives
• __has_trivial_move_assign returns true for address discriminated primitive types
• __has_trivial_move_constructor returns true for address discriminated primitives

[cor3ntin]

__builtin_is_replaceable - returns true for structs with address discriminated fields, and address discriminated primitives

This is intended, i think - replaceable implies assignment = move + destruction, it is not a permission to use memcpy.

__is_standard_layout returns true for structs with address discriminated fields and primitives, but I don't know what standard layout implies in this case

I think that's fine, standard layout does not imply triviality - it puts restriction on data member but not on special member functions.

__is_pod returns true for address discriminated primitives

pod does imply triviality so that should return false

__has_trivial_move_assign, __has_trivial_move_constructor

This seems wrong, it's probably an issue at class construction, where data().HasTrivialSpecialMembers is not adjusted correctly