Il 29/10/25 14:09, Frederick Virchanza Gotham via Std-Proposals ha scritto:
>
> Oliver works at Apple and he worked on the arm64e compiler, and here's
> what he said an hour or two ago in this thread:
>
> "For the topic at hand clang currently does not support trivial
> relocation of polymorphic types - and reports correctly that such are not."

And that makes clang non-conforming with trivial relocation as currently
specified in the working draft. The current patch against GCC¹ has this
test:

> struct Z {
> virtual ~Z () = default;
> Z (Z &&) = default;
> Z &operator= (Z &&) = default;
> };
>
> static_assert (std::is_trivially_relocatable_v <Z>, "");
> static_assert (std::is_replaceable_v <Z>, "");


¹ https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686902.html


On the other hand, I perfectly understand that there's little interest
at chasing a moving target; given the number of NB comments, maybe the
entire feature will change drastically, so why spending time
implementing it in its current form? I've myself stopped working on
libstdc++ patches (to make std::vector operations use TR there) for this
reason.


> Basically he's saying that the following assertion will always succeed:
>
> static_assert( false == (is_polymorphic_v<T> &&
> is_trivially_relocatable_v<T>) );

Again, that's non-conforming as per the working draft.


> On an arm64e computer, if you relocate a polymorphic object, and then
> invoke a virtual method, the attempt to access the vtable will cause a
> CPU trap because the vtable pointer will be incorrectly encrypted.

This is not the case; the vtable pointer gets correctly re-signed during
trivial relocation.


My 2 c,
--
Giuseppe D'Angelo