Re: [PATCH] Remove lto_global_var_decls, simplify necessary analysis for PR60060

2014-02-06 Thread Richard Biener
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? Do we stream

[PATCH] Remove lto_global_var_decls, simplify necessary analysis for PR60060

2014-02-05 Thread Richard Biener
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

Re: [PATCH] Remove lto_global_var_decls, simplify necessary analysis for PR60060

2014-02-05 Thread Jan Hubicka
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

Re: [PATCH] Remove lto_global_var_decls, simplify necessary analysis for PR60060

2014-02-05 Thread Richard Biener
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_cgraph always

Re: [PATCH] Remove lto_global_var_decls, simplify necessary analysis for PR60060

2014-02-05 Thread Jan Hubicka
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 those. We'd