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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
