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: Fri, 18 Jul 2014 12:03:35 +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>
> On 07/08/2014 02:50 PM, Jan Hubicka wrote:
> >I am looking into tracking dynamic types now. Obviously I need to set very
> >exact rules about when these may change.
> Let me first say that this area is somewhat in flux in the standard;
> if we have a model of what we want the rules to be for GCC, there's
> a good chance of getting them into the standard. There are several
> unresolved DRs in this area already (1027, 1116, 1776).
> >I think b variants are invalid
> Yes, by 3.8/7; we can't use 'a' to call foo after we've changed the
> object there to a C.
> >currently we also assume t1 to be invalid, but
> >t2 to be valid.
> I think the compiler ought to be able to treat both as undefined,
> because 'a' is either defined (t1) or allocated (t2) as a B, and B
> does not contain an array of char, so changing the dynamic type of
> that memory before the end of its storage duration ought to be
> But the standard doesn't currently say that, though it's along the
> lines of my proposed drafting for 1116 (which needs reworking).
> And I suppose that my notion of 'allocated type' can really only
> apply when using the library allocation functions in 220.127.116.11 and
> 18.104.22.168, not the inline placement new.
Thanks! I guess we will have chance to chat about this on the Cauldron?
As you probably know, for middle-end analysis it would be good if types was as
sticky as possible. The sucess of type based devirtualization is largely based
on the fact that it is hard to track a value of memory location by alias
analysis (as calls to external functions are generally believed to change it)
but it is easier to track type of a memory location, because the ways it can
change are limited to construcition/destruction and placement news.
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 repatively construct & destruct.
This is based on our arlier conversation where the outcome was that chaning
non-POD variable by placement new to different type is not defined.
Anything weakter 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..
So perhaps we can go with my dynamic type patch enforcing the strong
interpretation (no changes beyond construction/destruction once polymorphic
type lands on a given location) and document it (do we have convenient place in
the user documentation). If it turns out to be impractical, we can always
carefuly relax it?
Where I find current wording of DR1116?