This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Issue with LTO/-fwhole-program

On Fri, Jun 11, 2010 at 9:41 PM, Manuel López-Ibáñez
<> wrote:
> On 11 June 2010 20:48, Cary Coutant <> wrote:
>>> But if I understand correctly, mixed LTO/non-LTO + whole-program is
>>> almost never correct. So we should really emit a warning for this
>>> specific combination. I think making this mistake would be quite easy
>>> but hard to debug.
>> It's not only correct, it's essential. "Whole Program" doesn't mean
>> that the compiler has to see all the IR for the whole program.
>> Instead, the compiler has visibility over the whole program in the
>> sense that it knows what variables and functions are referenced and
>> defined by the non-LTO code. Linking your program with non-LTO code is
>> inescapable unless we start shipping language and system libraries as
>> archives of objects compiled with -flto (and remove all assembly code
>> from such libraries).
>> The plugin interface was designed to provide this essential
>> information to the compiler about all the non-LTO code; until Gnu ld
>> implements this or the collect2 interface provides something similar,
>> you're simply working with an incomplete implementation, and you'll
>> have to live with the limitations.
> 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.

Thank you for this piece of FUD.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]