[clang] Reland [Clang] Deprecate `__is_trivially_relocatable` (PR #139061)

Aaron Ballman via cfe-commits cfe-commits at lists.llvm.org
Mon May 12 12:20:44 PDT 2025


AaronBallman wrote:

> I don't know all the background here, so apologies if this is a silly question, but we have some code that's checking:
> 
> ```
> static_assert(__is_trivially_relocatable(std::pair<const int, int>));
> ```
> 
> which now triggers a -Wdeprecated-builtins warning.
> 
> But if I switch to `__builtin_is_cpp_trivially_relocatable` instead, it fails:
> 
> ```
> error: static assertion failed due to requirement '__builtin_is_cpp_trivially_relocatable(std::pair<const int, int>)'
> ```
> 
> Is this intentional? (I also tried `__builtin_is_replaceable`, and that also fails.)

I think it is intentional-ish. Clang came up with an extension (`__is_trivially_relocatable`) and we took it to WG21. The standards committee came up with a similar-but-not-the-same feature which we implemented (`__builtin_is_cpp_trivially_relocatable`). As with a lot of new extensions, we don't want to carry the new and old behavior forever, so we deprecate the old trait to start moving users to the standards-based functionality. According to the standard, that's not trivially relocatable. However, we do realize this leaves performance on the ground, so there are plans to add annotations to the standard library interface to claw that performance back in cases where we can (like `std::pair`), but that work hasn't been done yet.

I think the deprecation warning is reasonable and shouldn't be walked back; users can still use the old API and disable the diagnostic via pragmas/command line switch/etc if the performance characteristics of the standards-based APIs aren't sufficient.

https://github.com/llvm/llvm-project/pull/139061


More information about the cfe-commits mailing list