On Wed, 5 Feb 2014, Jan Hubicka wrote:
> > >
> > > Seems OK to me. I always had an impression that this machinery exists to
> > > make decls that are revmoed fro symbol table (optimized out) to land the
> > > debug info, but I think this is mostly broken by partitioning anyway,
> > > right?
> >
> >
> > Seems OK to me. I always had an impression that this machinery exists to
> > make decls that are revmoed fro symbol table (optimized out) to land the
> > debug info, but I think this is mostly broken by partitioning anyway, right?
> > Do we stream them at all?
>
> No, we don't stream tho
On Wed, 5 Feb 2014, Jan Hubicka wrote:
> >
> > When looking at PR60060, outputting the declaration debug info for
> > a local static variable twice (once via BLOCK_VARS and once via
> > calling the debug hook on all globals) I noticed that the
> > rest_of_decl_compilation call in materialize_cgra
>
> When looking at PR60060, outputting the declaration debug info for
> a local static variable twice (once via BLOCK_VARS and once via
> calling the debug hook on all globals) I noticed that the
> rest_of_decl_compilation call in materialize_cgraph always works
> on the empty lto_global_var_decl
When looking at PR60060, outputting the declaration debug info for
a local static variable twice (once via BLOCK_VARS and once via
calling the debug hook on all globals) I noticed that the
rest_of_decl_compilation call in materialize_cgraph always works
on the empty lto_global_var_decls vector (we
