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: Thu, 3 Jul 2014 20:11:53 +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> <20140703005620 dot GA25993 at kam dot mff dot cuni dot cz> <20140703013041 dot GB25993 at kam dot mff dot cuni dot cz> <53B4BDF9 dot 8030309 at redhat dot com>
> 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++:
> Any thoughts?
Thanks! I will take a look.
I would like to decide what to do with this approach. I can see
1) I can start explicitly tracking if type came from a declaration or was detected dynamically
(by seeing a vtable write or constructor call). Currently we don't do the second, but I would
like to understand if these make difference
2) The code in question first detect that a type in a given variable is fully constructed and
then starts tracking it across function calls. If needed I can check if my unwind stack contains
some additional constructors/destructors that may possibly be currently destructing the type
if it is valid to call destructor and construct same type there again.
If one can there destruct the type and build completely different type, we need updates elsewhere
in devirt machinery, too.