On 08/17/2013 05:44 PM, Jan Hubicka wrote:
1) we want the type to not have base because we may have inlined the
constructor.
During construction the vtables are filled by base's vtable and thus we can
not simply devirtualize based on the final virtual table without proving
that
constructor was not (partially) inlined.
If the constructor is inlined into the current function, then we can see
the most recent assignment to the vptr and use that for devirtualization.
I do not know if one can do
something like having automatic variable of class A and use placement new
to change it to class B.
This is something of a grey area in the standard, with a few defect
reports yet to be resolved. I think it should be undefined behavior.
Finally I decided to replace the lookup of base binfo by call to
get_binfo_at_offset. This is not possible. For example my base
variable can be:
struct {class A a; class B b} var;
and offset 10 may point to class B. Here I get an ICE since TYPE_BINFO
of the structure is NULL (it is not class).
I don't understand. In C++ a struct is a class.
I wonder if we can track functions that return pointers/values of objects
exactly of given type (i.e. no derivations).
If the function returns by value, it's always a value of that exact type.
Is the dynamic type upon return from constructor always known to be of
constructor's type?
Yes.
We may want to introduce assert_type_expr use like:
obj_ptr = assert_type_expr<class A> obj_ptr;
that can be dropped by FE for us to drive those more interesting cases, like
partial construction.
I guess we would need to be careful to insert those after vptr
assignments within the constructor body, as well.
Jason
