================
@@ -74,7 +74,7 @@ static_assert(__is_trivially_destructible(S3));
static_assert(!__is_trivially_copyable(S3));
static_assert(!__is_trivially_relocatable(S3)); //
expected-warning{{deprecated}}
//FIXME
-static_assert(__builtin_is_cpp_trivially_relocatable(S3));
+static_assert(!__builtin_is_cpp_trivially_relocatable(S3));
----------------
ojhunt wrote:
@rjmccall (I have no idea if pinging like this impacts GH behavior so this is
more a test than anything else)
So the issue here is that we weren't sure how to handle explicitly ptrauth
qualified values, and then with everything else didn't end up landing the
trivially_relocate support at all, and that PR is large enough that I would be
worried about landing it in llvm21 at this point.
@cor3ntin and I discussed this and thought that having this return false until
we actually supported trivial relocation was the best approach even though it
could in principle impact abi when we do enable it.
The trivially_relocate PR is over at
https://github.com/llvm/llvm-project/pull/144420 and you can see it is quite a
big one.
On the other hand it really only impact types containing address discriminated
values so if there were any issues the impact would be extremely restricted,
and assuming that the use of explicit pointer auth in code built with llvm21,
the most common place it would be encountered is when trivially relocating
polymorphic types which is something that I really don't like at all, and wish
was not permitted as IMO it's a bigger hazard than copy behavior due to it
maintaining the vtable pointer for a potentially truncated object.
https://github.com/llvm/llvm-project/pull/154490
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
