================
@@ -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

Reply via email to