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...