On 02/17/2014 03:55 PM, Jan Hubicka wrote:
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.
In the C++ front end we set TREE_PUBLIC app
On 02/15/2014 05:09 AM, Richard Biener wrote:
On Sat, 15 Feb 2014, Jan Hubicka wrote:
The code really seems to be adding only cases of zero sized classes.
zero-size as in with no fields? Then we can't do anything with such
classes and thus we don't need to record component aliases?
Right.
On Wed, 19 Feb 2014, Jan Hubicka wrote:
> > On Tue, 18 Feb 2014, Jan Hubicka wrote:
> >
> > > > > 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.
> > > > >
> On Tue, 18 Feb 2014, Jan Hubicka wrote:
>
> > > > 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 aliasi
On Tue, 18 Feb 2014, Jan Hubicka wrote:
> > > 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-P
> > 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?)
>
> Surely for accessing components of non-
On Tue, 18 Feb 2014, Richard Biener wrote:
> On Mon, 17 Feb 2014, Jan Hubicka wrote:
>
> > >
> > > 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 a
On Mon, 17 Feb 2014, Jan Hubicka wrote:
> >
> > 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
>
> 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"
On Mon, 17 Feb 2014, Jan Hubicka wrote:
> > On Fri, 14 Feb 2014, Jan Hubicka wrote:
> >
> > > > > This smells bad, since it is given a canonical type that is after the
> > > > > structural equivalency merging that ignores BINFOs, so it may be
> > > > > completely
> > > > > different class with c
> On Fri, 14 Feb 2014, Jan Hubicka wrote:
>
> > > > This smells bad, since it is given a canonical type that is after the
> > > > structural equivalency merging that ignores BINFOs, so it may be
> > > > completely
> > > > different class with completely different bases than the original.
> > >
On Sat, 15 Feb 2014, Jan Hubicka wrote:
> > > > This smells bad, since it is given a canonical type that is after the
> > > > structural equivalency merging that ignores BINFOs, so it may be
> > > > completely
> > > > different class with completely different bases than the original.
> > > > Ba
On Fri, 14 Feb 2014, Jan Hubicka wrote:
> > > This smells bad, since it is given a canonical type that is after the
> > > structural equivalency merging that ignores BINFOs, so it may be
> > > completely
> > > different class with completely different bases than the original. Bases
> > > are
>
> > > This smells bad, since it is given a canonical type that is after the
> > > structural equivalency merging that ignores BINFOs, so it may be
> > > completely
> > > different class with completely different bases than the original. Bases
> > > are
> > > structuraly merged, too and may be ex
> > This smells bad, since it is given a canonical type that is after the
> > structural equivalency merging that ignores BINFOs, so it may be completely
> > different class with completely different bases than the original. Bases
> > are
> > structuraly merged, too and may be exchanged for norma
On Fri, 14 Feb 2014, Jan Hubicka wrote:
> Hi,
> I have noticed that record_component_aliases is called during LTO time and it
> examines contents of BINFO:
> 0x5cd7a5 record_component_aliases(tree_node*)
> ../../gcc/alias.c:1005
> 0x5cd4a9 get_alias_set(tree_node*)
> ../../gcc/alia
On 02/13/2014 04:48 PM, Jan Hubicka wrote:
all bases are also fields of within the type, so the second loop should notice
all the types seen by first loop if I am correct?
Yes, except that empty bases don't get fields because they have no data.
But since they have no data they aren't interest
Hi,
I have noticed that record_component_aliases is called during LTO time and it
examines contents of BINFO:
0x5cd7a5 record_component_aliases(tree_node*)
../../gcc/alias.c:1005
0x5cd4a9 get_alias_set(tree_node*)
../../gcc/alias.c:895
0x5cc67a component_uses_parent_alias_set_from(t
18 matches
Mail list logo
