>
> Yeah, ok. But we treat those types (B and C) TBAA equivalent because
> structurally they are the same ;) Luckily C has a "proper" field
> for its base (proper means that offset and size are correct as well
> as the type). It indeed has DECL_ARTIFICIAL set and yes, we treat
> those as "real" fields when doing the structural comparison.
Yep, the difference is that depending if C or D win, we will end up walking the
BINFO or not. So we should not depend on the BINFo walk for correctness.
>
> More interesting is of course when we can re-use tail-padding in
> one but not the other (works as expected - not merged).
Yep.
>
> struct A { A (); short x; bool a;};
> struct C:A { bool b; };
> struct B {struct A a; bool b;};
> struct C *p2;
> struct B *p1;
> int
> t()
> {
> p1->a.a = 2;
> return p2->a;
> }
>
> > Yes, zero sized classes are those having no fields (but other stuff,
> > type decls, bases etc.)
>
> Yeah, but TBAA obviously doesn't care about type decls and bases.
So I guess the conclussion is that the BINFO walk in alias.c is pointless?
Concerning the merging details and LTO aliasing, I think for 4.10 we should
make C++ to compute mangled names of types (i.e. call DECL_ASSEMBLER_NAME on
the associated type_decl + explicitly mark that type is driven by ODR) and then
we can do merging driven by ODR rule.
Non-ODR types born from other frontends will then need to be made to alias all
the ODR variants that can be done by storing them into the current canonical
type hash.
(I wonder if we want to support cross language aliasing for non-POD?)
I also think we want explicit representation of types known to be local to
compilation
unit - anonymous namespaces in C/C++, types defined within function bodies in C
and
god knows what in Ada/Fortran/Java.
Honza
>
> Richard.
