This is the mail archive of the
mailing list for the GCC project.
Re: Strenghten assumption about dynamic type changes (placement new)
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Jason Merrill <jason at redhat dot com>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, gcc-patches at gcc dot gnu dot org
- Date: Sat, 19 Jul 2014 17:44:08 +0200
- Subject: Re: Strenghten assumption about dynamic type changes (placement new)
- Authentication-results: sourceware.org; auth=none
- References: <20140702201805 dot GB15987 at kam dot mff dot cuni dot cz> <53B49446 dot 7090402 at redhat dot com> <20140708135023 dot GC27691 at kam dot mff dot cuni dot cz> <53C87213 dot 1050604 at redhat dot com> <20140718100335 dot GA7671 at kam dot mff dot cuni dot cz> <53CA76FF dot 8080101 at redhat dot com>
> 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.
To support this safely I really think we will need to mark placement new
in the gimple code via builtin for a short while.
As discussed today. I may make a difference in between objects allocated in
char buffers and objects allocated via normal new and propagate only across
the second ones, but that seems a bit slipperly, too.
> >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.
I still do not see how this can work with aliasing rules - if the two objects
allocated do not overlap, we will freely overlap the old and new objects.
But adding extra builtin that will (for some time) keep the two pointer distinct
should not make it any worse.
> >Where I find current wording of DR1116?