This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Strenghten assumption about dynamic type changes (placement new)

On 07/18/2014 11:03 AM, Jan Hubicka wrote:
I really only care about types containing virtual table pointers to not change,
so non-PODs are out of game.  Current propagation is built around assumption that
once polymorphic type is constructed on a given location it won't change to
completely different type, only possibly repetitively construct & destruct.
This is based on our earlier conversation where the outcome was that changing
non-POD variable by placement new to different type is not defined.

For a variable, yes. If I have a char array buffer (possibly wrapped in a class, e.g. std::aligned_storage), it is OK to construct one non-POD object, destroy it, then construct one of a different type in the same space, just like if we have two automatic variables in different blocks that happen to occupy the same location on the stack. Again, this really needs to be specified better in the standard.

Anything weaker will probably need some cooperation from the frontend - I
suppose best tie we have is the fact that you can't use 'a' to call foo after
changing object. If placement news was marked for some time by a builtin, we
could effectively thread the re-allocated objects as a new memory locations.

My concern about treating them as different memory locations is danger of code reordering causing the lifetimes of the old and new objects to overlap.

Where I find current wording of DR1116?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]