https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77896
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77896
--- Comment #6 from Jonathan Wakely ---
(In reply to Ryan Johnson from comment #4)
>puts("\nWorks ok-ish:");
>Jekyl* x = new Jekyl;
>whatami(x);
>puts("\nJekyl?");
>delete x;
I think this would be OK if it did "delete (AlterE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77896
--- Comment #5 from Ryan Johnson ---
In an ideal world, C++ would disallow such behavior by default, with a function
attribute of some kind that flags cases where a type change might occur (kind
of like how c++11 assumes `nothrow()` for destructo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77896
--- Comment #4 from Ryan Johnson ---
Yikes. That explains it, all right.
I never would have thought of an object destroying itself and changing its type
with placement new... I guess it must be subject to the same restrictions as
`delete this`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77896
--- Comment #3 from Andrew Pinski ---
Basically what I am trying to say is there is a lot of analysis needed to
determine if the lifetime of object does not end during a call to a virtual
function.
> Altering the test case to trigger speculative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77896
--- Comment #2 from Andrew Pinski ---
(In reply to Ryan Johnson from comment #1)
> Given that an object's vtable is fixed over its lifetime,
Yes but functions including virtual functions can deconstruct the object and
then call inplacement new o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77896
--- Comment #1 from Ryan Johnson ---
It appears that multiple calls to different virtual functions of the same
object are not optimized, either (each performs the same load-load-jump
operation).
