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

[John McCall <rjmccall at apple dot com>]

On Jun 29, 2012, at 2:23 PM, Rafael Espíndola wrote:
>> There's no "for a long time" here.  The ABI does not allow us to emit these
>> symbols with non-coalescing linkage.  We're not going to break ABI
>> just because people didn't consider a particular code pattern when they
>> hacked in devirtualization through external v-tables.
> 
> If we take "the ABI" to mean compatibility with released versions of
> the compilers, then it *is* broken, as released compilers assume
> behavior that is not guaranteed by the ABI (the document). It is not
> possible to avoid all incompatibilities.

By "breaking the ABI", I mean changing the required output of
compilers that conform to it.  It is understood that compilers will
occasionally have bugs that cause them to not conform;  as a
somewhat trivial example, both gcc and clang have mis-mangled
symbols in the past.  Typically, compiler implementers choose to fix
those bugs, rather than trying to codify them by modifying the ABI.

Again, the ABI clearly expects that every object file that references
an inline function will define it, and do so with coalescing linkage.
That is an invaluable invariant.  Our proposed visibility-modifying
optimization is hardly the only reasonable consumer of it.

As with most compatibility problems, it would be better if no compiler
had ever strayed from the One True Path, and yet it's happened.
Given that the chance of actual incompatibility in practice is low —
as I believe I've argued several times — I continue to believe that
the proper response is to just fix the bug, rather than imposing a
novel and permanent constraint on ourselves out of unmotivated worry.

Also, as a point of order:  when you said you were going to make
a proposal to the GCC list, I was under the impression that we'd
reached some level of consensus.

John.