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.
