[Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior

["andrew2085 at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349

--- Comment #35 from Andrew Downing <andrew2085 at gmail dot com> ---
I agree that the new implicit object creation rules sound very difficult to
implement correctly especially because the behavior in C is different. I'm
curious to see how that will all play out.

In this situation though, if we use the C rules for what memcpy does C17 6.5/6
https://web.archive.org/web/20181230041359if_/http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf#section.6.5,
the effective type shouldn't be changed. The declared type of both objects is
known to the compiler. In the first memcpy the declared type of the object is
unsigned char[8], in the second memcpy the declared type of the object is
double. Placement new changes the effective type to std::uint64_t, but that
doesn't change the behavior of memcpy. Footnote 88 says "Allocated objects have
no declared type.". I believe calling a function defined in another TU that
returns a pointer also has to be considered to return a pointer to an object
with no declared type, because the object's declaration isn't visible. In this
situation though, the declared types are visible, and so a modifying access, or
memcpy, or memmove shouldn't change the effective type.

If gcc is changing the effective type with every memcpy no matter what, that
would be the wrong thing to do right? Especially since you're saying that it's
the reason that this example isn't being compiled correctly.