This is the mail archive of the gcc-patches@gcc.gnu.org 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/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 18.6.1.1 and 18.6.1.2, not the inline placement new.

Jason


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