Issue with LTO/-fwhole-program

[Richard Guenther]

On Fri, Jun 11, 2010 at 2:22 PM, Manuel López-Ibáñez
<lopezibanez@gmail.com> wrote:
> On 11 June 2010 14:07, Richard Guenther <richard.guenther@gmail.com> wrote:
>> On Fri, Jun 11, 2010 at 2:04 PM, Bingfeng Mei <bmei@broadcom.com> wrote:
>>> Hi,
>>>
>>> I am still puzzled by the effect of LTO/-fwhole-program.
>>> For the following simple tests:
>>>
>>> a.c:
>>>
>>> #include <stdio.h>
>>> int v;
>>>
>>> extern void bar();
>>> int main()
>>> {
>>>  v = 5;
>>>  bar();
>>>
>>>  printf("v = %d\n", v);
>>>  return 0;
>>> }
>>>
>>> b.c:
>>> int v;
>>> void bar()
>>> {
>>>  v = 4;
>>> }
>>>
>>> If I just compile plainly, the output is:
>>> v = 4
>>>
>>> If I compile  as:
>>> ~/work/install-x86/bin/gcc  a.c -O2 -c -save-temps -flto
>>> ~/work/install-x86/bin/gcc  b.c -O2 -c -save-temps
>>> ~/work/install-x86/bin/gcc  a.o b.o -O2 -fuse-linker-plugin -o f -flto -fwhole-program
>>>
>>> The output is:
>>> v = 5
>>>
>>> We get two copies of v here. One is converted to static by whole-program optimizer,
>>> and the other is global. I know I can add externally_visible in a.c to solve
>>> the issue.  But since compiler is not able to give any warning here, it could make
>>> program very tricky to debug.
>>>
>>> What is the value to convert variables to static ones? I know unreferenced ones can
>>> be optimized out, but this can be achieved by -fdata-sections & -gc-collection as
>>> well, I believe.
>>
>> You make inter-procedural/file data-flow operations possible.
>
> But this is a bug, isn't it?

No, you lied to the compiler by specifying -fwhole-file.

Richard.

> Cheers,
>
> Manuel.
>