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

Dave Korn wrote:
On 13/06/2010 20:55, Ian Lance Taylor wrote:
David Brown <> writes:

If -flto were to activate the -fno-common flag, would that then catch these potential problems with a linker error?
We could perhaps do that for C/C++ code, but Fortran relies on common symbols.

Well we shouldn't do it for plain C either, or at the very least should make it depend on the -std= option in effect, but since the code is entirely valid and legitimate C, I think we should acknowledge this is a weakness in our compiler. The original testcase is a perfectly straightforward bit of C89; there are two compatible tentative declarations of a variable of type int called "v". We don't want to have to argue that one is in fact a variable of type "int compiled with LTO" in order to back-justify some argument that they are not the same and this example violates some (vague and not standard-specified) C equivalent of the ODR.


I agree that banning common symbols is not a complete solution. But perhaps it may be a partial solution until some more complete solution is found and implemented?

How about having a warning flag -Wcommon-lto which will produce a warning if LTO is used along with common data, and which is enabled by default by -flto? For code that does not use common symbols, everything works as expected and the user gets LTO'ed code. But if the code /does/ use common symbols, you get a warning that the code may be incorrect if a common symbol is declared in both LTO and non-LTO object files. It is then up to the user to ignore the warning, or fix the common symbols.

This is not a complete fix - ideally, LTO should work fine even with common symbols. And failing that, the warning (or error) message should only come if there really is a conflict, rather than just a potential conflict. But I would think that a check like this is a relatively simple feature, and would add an extra level of safety to LTO.

Incidentally, the original poster used -fwhole-program. Is this conflict only an issue when the -fwhole-program flag is used? If that's the case, then the warning could be conditional on that flag too, meaning even rarer circumstances when false positives would be issued.


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