[cfe-dev] GCC and Clang produce undefined references to functions with vague linkage
rafael.espindola at gmail.com
Fri Jun 29 11:40:42 PDT 2012
Richi asked me to also report a gcc bug:
> 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.
More information about the cfe-dev