[lto]: patch committed and new bug.

[Jim Blandy]

Kenneth Zadeck <zadeck@naturalbridge.com> writes:
> This patch is the first cut at restructuring the code to write function
> bodies to also
> handle the var_decl initializers.
>
> This code does not work.  The (first) problem is in the codesourcery
> side of this.  I am sure that when that gets fixed, there will be bugs
> on my side.  The problem is that lto_read_var_init gets called with NULL
> for the data parameter.  This makes life difficult.
>
> Consider the test case:
>
> =================
> struct foo_
> {
>   int a;
>   int b;
> } foo;
>
> int bar (int a)
> {
>   struct foo_ foo = {1, 2};
>
>   return foo.a + 6;
> }
> =================
> and the commands:
> ./xgcc -flto -c -O2 ../../gccLTO/gcc/test6.c -o test6.o
> gdb --args ./lto1 -O2 test6.o -o test6.o.o
>
> #0  0x000000000041cfca in lto_read_body (fd=0x11c9730,
> context=0x7fffcc8cd2e0,
>     t=0x2b8ade2ac6e0, data=0x0, in_function=0 '\0')
>     at ../../gccLTO/gcc/lto/lto-read.c:1524
> #1  0x000000000041d62b in lto_read_var_init (fd=0x11c9730,
>     context=0x7fffcc8cd2e0, var_decl=0x2b8ade2ac6e0, data=0x0)
>     at ../../gccLTO/gcc/lto/lto-read.c:1672
> #2  0x0000000000411516 in lto_read_variable_formal_parameter_constant_DIE (
>     fd=0x11c9730, die=0x2b8adef111d2, abbrev=0x11e8200,
> context=0x7fffcc8cd2e0)
>     at ../../gccLTO/gcc/lto/lto.c:2050
>
> The data=0x0 tells a bad story.  However, one that should be a quick fix.

What's going on here is that FOR_EACH_STATIC_INITIALIZER is not
visiting the nodes for either 'foo' in the test program: the global
foo has no initializer, and the local foo isn't static.  So the .o
file has no .gnu.lto_foo section.

So perhaps Mark's guess in the earlier about that being the right
thing to call wasn't right.