Richi asked me to also report a gcc bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53808
> But that's pervasively true in C++ — the linker has to eliminate duplicates > all the time. Idiomatic C++ code ends up plunking down hundreds, if > not thousands, of inline functions in every single translation unit. This is > already a massive burden for linking C++ programs, particularly in debug > builds. Adding a few extra symbols when the optimizer determines that > it can devirtualize, but declines to inline, is essentially irrelevant. > > In fact, it is particularly unimportant because it's very likely that this > duplicate > will be in the same DSO as the vtable. That means that the first solution > imposes some extra work on the static linker alone (but again, only when > devirtualizing a call to a function we don't want to inline!) while preserving > our ability to reduce work for the dynamic linker (since calls do not rely > on address equality of the function across translation units). The second > solution is an irrevocable guarantee that every symbol mentioned in > a strong vtable *must* be exported to the whole world. > > Also recall that these symbols can already be emitted in arbitrary > other translation units — we cannot change the ABI to say that these > symbols are *only* emitted in the file defining the v-table. I would just like to point out that the ABI could says that they only *need* to be emitted in the file with the vtable, but yes, for a long time it would have to support the symbols showing up in other translation units produce by older compilers. > Finally, both the language standard and the ABI are clearly designed > around an assumption that every translation unit that needs an inline > function will emit it. > > John. Cheers, Rafael
