On 12 June 2010 01:27, Richard Guenther <richard.guent...@gmail.com> wrote: > On Fri, Jun 11, 2010 at 9:41 PM, Manuel López-Ibáñez > <lopeziba...@gmail.com> wrote: >> On 11 June 2010 20:48, Cary Coutant <ccout...@google.com> 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.
I don't believe the above for a second. But I want to have real answer if I find such assertion in the wild. I think Ian's answer has been the best so far and I totally agree with his proposal. Sorry if I conveyed the hypothetical case too literally. Manuel.
