This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC and Clang produce undefined references to functions with vague linkage


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]