On 14/06/2010 11:22, Dave Korn wrote:
On 14/06/2010 05:43, Ian Lance Taylor wrote:
David Brown<david.br...@hesbynett.no> writes:
After doing a bit more reading and thinking, it seems to me that
-fwhole-program will be used in most cases where LTO is used. You use
-flto when compiling each source file, then link them with gcc with
-flto and -fwhole-program. Except in the case of libraries or other
files which need external symbols, you will want that combination to
generate optimal code. So if this combination alone, without common
symbols, is going to cause problems, then this would be a much bigger
issue than if it is only triggered by common symbols.
That scenario is fine.
You can look back to see the problematic case posted earlier. It was
a case where one file was compiled with -flto, one file was compiled
without -flto, both files defined a common symbol with the same name,
the object files were linked together using -flto -fwhole-program, and
the gold plugin was not used. All elements are essential to recreate
the problem.
Given how many standard libraries export common symbols, I wonder if it
won't actually happen quite often. "nm /usr/lib/*.a | grep ' C '" gives a
fair few hits for me.
It seems unlikely that common symbols in a library will be a problem,
since it is very unlikely that the same common symbols will be defined
in the library /and/ in user code, and it is very unlikely that
different parts of the library would be compiled with different -flto
settings.
However, such libraries would give false (hopefully false!) positives in
a warning message triggered by the use of common symbols. Is it
possible for such a warning message to distinguish between common
symbols from library files and common symbols from object files? Would
that be too risky?
