Issue with LTO/-fwhole-program

[David Brown]

On 12/06/2010 16:52, Richard Guenther wrote:
> On Sat, Jun 12, 2010 at 3:32 PM, David Brown<david.brown@hesbynett.no>  wrote:
>> Ian Lance Taylor wrote:
>>>
>>> Manuel López-Ibáñez<lopezibanez@gmail.com>  writes:
>>>
>>>> This also means that linking your program with non-LTO+whole-program
>>>> code may lead to miscompilations without any warning, which is really
>>>> bad. I don't think it is a reasonable limitation and we will get bad
>>>> press when programs start breaking for users. They won't care (and
>>>> they won't even listen) about the reasons. The conclusion will be: LTO
>>>> is broken in GCC, and just use another compiler.
>>>
>>> The limitation isn't all that bad.  If you want to use
>>> -fwhole-program, I think the basic rule is this: compile all your code
>>> with -flto, and don't define variables or functions which are
>>> referenced by any code which is not yours.
>>>
>>> I think adding a warning for this case would be great, if we can
>>> figure out how to do it.  But I also think that a clear statement in
>>> the documentation will avoid most user problems.
>>>
>>> Ian
>>>
>>
>> To me, this sounds like you are safe as long as you stick to the "one
>> definition rule".  This is a requirement for C++ - the original example with
>> "int v" definitions in two files would be illegal in C++, while it is legal
>> in C.
>
> Correct.  In failure mode with -fno-common you would get a linker
> error instead of silent miscompiles.
>

I work as an embedded systems developer, especially for small 
microcontrollers.  In my programs, the huge majority of code is written 
by me - I don't even make much use of standard libraries (other than 
gcc's target support libraries, of course).  So if my questions or 
comments here sound a bit silly, it's just that I don't normally have to 
work with code from multiple sources.

I use the -fno-common flag in all my compilations - I see it as a 
mistake to have uninitialised global data defined in more than one place 
at a time.

I can see that such "common" segment data can occur in legacy code, but 
is it much used in modern programming?  I would think that while many C 
programmers (myself included) prefer to stick to C rather than C++ for 
many reasons, many also like to take some of the good ideas from C++. 
Just as many features of C++ have become part of newer C standards, so I 
think have some of the ideas of clearer structure and modularisation - 
including the clear separation of interface (headers) and implementation 
(c files), and appropriate use of "extern" and "static".  Such programs 
should compile cleanly with -fno-common.

If -flto were to activate the -fno-common flag, would that then catch 
these potential problems with a linker error?  This will give some false 
positives, of course, but it is better to produce suboptimal code (i.e., 
disable LTO) than to risk producing wrong code.

If it turns out that common data is so common that it must be possible 
to enable LTO with common data, then this could perhaps be reduced to a 
warning when LTO and common data are used together, or with a specific 
"-fi-know-what-im-doing" flag to disable the no-common errors.


>> Assuming I'm correct here, then perhaps there could be a warning or error
>> message that is triggered by breaking the ODR, and which could be enabled
>> automatically by the -flto flag.  Perhaps existing checking mechanisms from
>> C++ can be used here.
>
> It's not easy without using the gold linker-plugin as we do not see the
> other definition.  With using the gold linker-plugin we can detect the
> situation and do the right thing (as proposed by the patches from Binfeng).
>
> Richard.
>
>> David
>>
>>
>