Manuel López-Ibáñez <lopeziba...@gmail.com> writes: > On 11 June 2010 15:04, Bingfeng Mei <b...@broadcom.com> 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. Ian
