Dave Korn wrote:
On 13/06/2010 20:55, Ian Lance Taylor wrote:
David Brown <da...@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
