On Thu, Jul 3, 2014 at 4:20 AM, Jason Merrill <ja...@redhat.com> wrote: > On 07/02/2014 06:30 PM, Jan Hubicka wrote: >> >> But this is one of things that was not quite clear to me. I know that >> polymorphic type A >> was created at a give memory location. THis means that accesses to that >> location in one >> alias class has been made. >> Now I destroy A and turn it into B, construct B and make memory accesses >> in different >> alias set. I see this has chance to work if one is base of another, but >> if B is completely >> different type, I think strick aliasin should just make those accesses to >> not alias and in turn >> make whole thing undefined? > > > Right, if they're unrelated types the accesses don't alias (3.10p10). > > On the subject of aliasing, there's a proposal to add explicit alias sets to > C++: > > http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3988.pdf > > Any thoughts?
Well, but deleting the object at *p and constructing a new one with different alias set there doesn't make it valid for GCC to move loads/stores across that destruction/construction point, no? With placement new / delete they will basically be a no-op and be "invisible" in the IL - so what avoids GCC, for example from insn scheduling, to mess things up here? (the GCC middle-end memory model does - but as far as I understand Honza want's to play tricks to get around that, no?) Richard. > Jason >
