This is the mail archive of the 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 01:18 PM, Jan Hubicka wrote:
> > >We propagate types from places we know instances are created across pointers
> > >passed to functions.  Once non-POD type is created at a given memory location,
> > >one can not change its type by placement_new into something else.
> > 
> > Hmm.  If the memory location is untyped (i.e. from malloc) or a
> > character array, or a union, you can indeed destroy an object of one
> > type and create an object of a different type in that location.
> > 
> > >Jason, this assumes that one can not destroy the type and re-construct same
> > >type at the same spot.
> > 
> > That is an invalid assumption; you can destroy one object and
> > construct a new one in the same location.  Doing it within a method
> > would be unusual, but I don't think there's a rule against it.
> The types get currently are one comming from declarations of variables
> and parameters passed by reference.
> Can I really destroy it/allocate new type/destroy new type/allocate back the original
> type (or terminate the program) so the destruction at the end of the lifetimate of the
> variable apsses?
> I suppose we should keep track if memory location is comming from declaration or 
> it is dynamically typed (i.e. type seen from calling constructor)? Currently we don't
> deal with dynamic types, but I have patches for that.

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?


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