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

Manuel LÃpez-IbÃÃez <> writes:

> On 11 June 2010 15:04, Bingfeng Mei <> wrote:
>> Well, mixed LTO/non-LTO is quite useful. For example, we have mixed C/assembly
>> Application. Gold support for our target is still far away. I found -fwhole-program
>> is very important for our size optimization.
> 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.

As I understand it, that combination often can be correct.  In this
particular case it failed because there a common symbol appeared in
one file compiled with -flto and in one file compiled without -flto.
But mixing -flto/-fno-lto and common symbols in that way is not going
to be typical.  In general your program should be fine as long as you
don't try to define the same symbol with both -flto and -fno-lto,
which is exactly the case you will be in if statically linking with a
typical C library which was not compiled with -flto.

So while clearly we should diagnose this case, it's going to be
difficult to implement without giving up something useful.  It's going
to require linker support.  It works already with gold, so this means
adding something to the GNU linker.  Frankly I think the most
straightforward approach would be to add plugin support to the GNU
linker.  There is nothing gold specific about the LTO linker plugin.
Of course that approach wouldn't help on systems which can not use the
GNU linker, but we're kind of stuck on those systems anyhow.


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