On 12/06/2010 16:52, Richard Guenther wrote:
On Sat, Jun 12, 2010 at 3:32 PM, David Brown<david.br...@hesbynett.no> wrote:
Ian Lance Taylor wrote:
Manuel López-Ibáñez<lopeziba...@gmail.com> writes:
This also means that linking your program with non-LTO+whole-program
code may lead to miscompilations without any warning, which is really
bad. I don't think it is a reasonable limitation and we will get bad
press when programs start breaking for users. They won't care (and
they won't even listen) about the reasons. The conclusion will be: LTO
is broken in GCC, and just use another compiler.
The limitation isn't all that bad. If you want to use
-fwhole-program, I think the basic rule is this: compile all your code
with -flto, and don't define variables or functions which are
referenced by any code which is not yours.
I think adding a warning for this case would be great, if we can
figure out how to do it. But I also think that a clear statement in
the documentation will avoid most user problems.
Ian
To me, this sounds like you are safe as long as you stick to the "one
definition rule". This is a requirement for C++ - the original example with
"int v" definitions in two files would be illegal in C++, while it is legal
in C.
Correct. In failure mode with -fno-common you would get a linker
error instead of silent miscompiles.
I work as an embedded systems developer, especially for small
microcontrollers. In my programs, the huge majority of code is written
by me - I don't even make much use of standard libraries (other than
gcc's target support libraries, of course). So if my questions or
comments here sound a bit silly, it's just that I don't normally have to
work with code from multiple sources.
I use the -fno-common flag in all my compilations - I see it as a
mistake to have uninitialised global data defined in more than one place
at a time.
I can see that such "common" segment data can occur in legacy code, but
is it much used in modern programming? I would think that while many C
programmers (myself included) prefer to stick to C rather than C++ for
many reasons, many also like to take some of the good ideas from C++.
Just as many features of C++ have become part of newer C standards, so I
think have some of the ideas of clearer structure and modularisation -
including the clear separation of interface (headers) and implementation
(c files), and appropriate use of "extern" and "static". Such programs
should compile cleanly with -fno-common.
If -flto were to activate the -fno-common flag, would that then catch
these potential problems with a linker error? This will give some false
positives, of course, but it is better to produce suboptimal code (i.e.,
disable LTO) than to risk producing wrong code.
If it turns out that common data is so common that it must be possible
to enable LTO with common data, then this could perhaps be reduced to a
warning when LTO and common data are used together, or with a specific
"-fi-know-what-im-doing" flag to disable the no-common errors.
Assuming I'm correct here, then perhaps there could be a warning or error
message that is triggered by breaking the ODR, and which could be enabled
automatically by the -flto flag. Perhaps existing checking mechanisms from
C++ can be used here.
It's not easy without using the gold linker-plugin as we do not see the
other definition. With using the gold linker-plugin we can detect the
situation and do the right thing (as proposed by the patches from Binfeng).
Richard.
David
