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/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?

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.

Thanks!
Honza
> 
> Jason


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