This is the mail archive of the gcc@gcc.gnu.org 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 <david@westcontrol.com> 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.

    cheers,
      DaveK


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.

David


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