This is the mail archive of the
mailing list for the GCC project.
Re: Strenghten assumption about dynamic type changes (placement new)
- From: Jason Merrill <jason at redhat dot com>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Fri, 18 Jul 2014 02:02:11 +0100
- 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>
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 undefined.
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 184.108.40.206 and 220.127.116.11,
not the inline placement new.