http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55395
--- Comment #10 from Jan Hubicka <hubicka at ucw dot cz> 2012-12-04 16:25:36
UTC ---
> It is always used if available and there is no other way to generate the
> location info for it (which for vars that were removed from the varpool is
> probably always, I bet those aren't assigned memory locations). The question
> is of course if it can successfully generate something out of it or not, but
> you can't guess that before it tried.
> For the invalid error part of this PR, it would be just important that it
> doesn't set DECL_INITIAL to error_mark_node, but some other magic value which
> says, this decl had non-zero initializer, but ignore the other details about
> it. Of course to make the debug info more complete you really should keep the
OK, what value it should be? We always used error_mark_node with this meaning
both in LTO and cgraph.
> initializer.
> Aren't you building mozilla with LTO without -g anyway, given that LTO screws
> up debug info so terribly that it isn't useful at all?
I build -g to at least catch the ICEs. Of course we should work towards making
-g
useful not useless.
> Can you come up with some short testcase that would show what kind of large
> constructors you care about?
static int a[]={huge sequence of numbers};
In C++ we have a lot of class constructors and vtables that comes from headers
and can go away...
