[Bug libstdc++/106547] std::variant::emplace goes into an infinite recursion with certain weird trivially copyable types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106547 --- Comment #3 from Jiang An --- (In reply to Valentine Anderson from comment #2) > From what I understand, the key feature of trivially copyable types is that > memcpy‘ing an object of such a type onto another object is equivalent to a > copy assignment. So it is possible to trivially copy such an object, using > memcpy. The current standard wording only guarantees that such copy is OK when the destination object is already created. A trivially copyable class is usually also an implicit-lifetime class, so memcpy is usually sufficient to create that object. But there're also weird trivially copyable class that is not an implicit-lifetime class (e.g. the class may have deleted copy/move ctors and trivial assignment operators). Moreover, it doesn't seem suitable to use memcpy in the cases involved in this issue...
[Bug libstdc++/106547] std::variant::emplace goes into an infinite recursion with certain weird trivially copyable types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106547 --- Comment #2 from Valentine Anderson --- >From what I understand, the key feature of trivially copyable types is that memcpy‘ing an object of such a type onto another object is equivalent to a copy assignment. So it is possible to trivially copy such an object, using memcpy.
[Bug libstdc++/106547] std::variant::emplace goes into an infinite recursion with certain weird trivially copyable types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106547 Jiang An changed: What|Removed |Added CC||de34 at live dot cn --- Comment #1 from Jiang An --- Well, is_trivially_copyable looks like a red herring - it doesn't really mean that we can trivially copy such an object in some way.
[Bug libstdc++/106547] std::variant::emplace goes into an infinite recursion with certain weird trivially copyable types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106547 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-08-06
