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. > 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 > >
