Date: Tue, 21 Oct 2025 12:59:17 -0400
Hi Lisa,
I would like to assure you that I considered what you wrote carefully.
Weak linkage is in no way an optimization techinque.
By definition, compilers don’t choose which symbols are chosen by the linker.
To be clear, you said “in almost all* usage, weak linkage is an optimization technique”.
I don’t believe this to be true.
Weak linkage in C++ is used because, in order to make sure .o files can always link, a TU has to have definitions of all functions that might be needed, even if they are also present in other places.
John .
> On Oct 20, 2025, at 8:55 PM, Lisa Lippincott <lisa.e.lippincott_at_[hidden]> wrote:
>
> On Oct 20, 2025, at 12:53 PM, John Spicer <jhs_at_[hidden]> wrote:
>>
>> This is not even remotely true.
>>
>> In most implementations weak linking is used for all inline functions where the implementation chooses not to inline, or in which a pointer to the function is taken.
>>
>> It is also used for all instantiation of functions.
>
> John, I feel like, in your haste, you have neglected to consider what I wrote carefully. (Or perhaps I am confused as to the referent of “this” in the first sentence, which I have taken to be the content of my earlier message.)
>
> I agree with your second and third sentences, which describe common practice. But where there is no possibility of pointer comparison, it is not a practice required by the standard or by any ABI with which I am familiar. Compilers often choose to use weak linking because it is seen as an optimization. They remain free to eschew weak linking in these cases, and they remain free to choose the symbol names to which they weakly link.
>
> In fact, our recent experience with GCC reminds us that weak linking inhibits other optimizations, and I would not be surprised to find that a less promiscuous application of weak linking would provide a desirable optimization for some programs.
>
> There are many ways to use weak linking in a less promiscuous way without completely eliminating its advantages. To pick an extreme example, a compiler may, acting unilaterally, weakly link a direct function call to a symbol name that encodes a hash of the compiler’s intended code. Doing so would increase code size only when different translation units produce different code for the same function, or when a different compiler is used. In return, the compiler gains insight into the unspecified aspects of the function’s behavior, and can use that information to optimize code surrounding the call.
>
> Would that be an improvement? It might be; I don’t know. But it is an allowed implementation technique.
>
> —Lisa
>
>
>>
>> John.
>>
>>
>>
>>> On Oct 20, 2025, at 3:39 PM, Lisa Lippincott <lisa.e.lippincott_at_[hidden]> wrote:
>>>
>>>
>>>> On Oct 20, 2025, at 8:52 AM, John Spicer via SG21 <sg21_at_[hidden]> wrote:
>>>>
>>>> The problem is that the language does not provide a way to allow people to protect themselves from this situation. I would not say it is mistake because it could involve libraries written by people that have never met one another.
>>>>
>>>> IMO, it *should* be possible to lock down a semantic to a function or a “component” but it is not possible with P2900, so you have a feature with very sharp edges that are hard for people to understand.
>>>
>>>
>>> I think you may be overlooking the fact that, in almost all* usage, weak linking is an optimization technique, not a requirement. If users are clamoring for weak linking to be limited in some way, implementations are free to respond. An implementation that limits its use of weak linking may be easier for some users to understand, and may also provide inter-procedural optimizations that are unavailable when using weak linking.
>>>
>>> In P2900, we chose to continue to make allowances allow for weak linking, and that does have an effect on the design. But we did nothing to require weak linking where there was no requirement before; it’s still largely optional.
>>>
>>>
>>> *In the one situation where weak linking is essentially required — comparison of pointers to nonmember functions defined in more than one translation unit — my understanding is that some implementations, particularly those using dynamic linking, are routinely nonconforming anyway. IMHO, we would be better off relaxing the pointer comparison rules, but I’m not planning to write that paper.
>>>
>>> —Lisa
>>>
>>
>
I would like to assure you that I considered what you wrote carefully.
Weak linkage is in no way an optimization techinque.
By definition, compilers don’t choose which symbols are chosen by the linker.
To be clear, you said “in almost all* usage, weak linkage is an optimization technique”.
I don’t believe this to be true.
Weak linkage in C++ is used because, in order to make sure .o files can always link, a TU has to have definitions of all functions that might be needed, even if they are also present in other places.
John .
> On Oct 20, 2025, at 8:55 PM, Lisa Lippincott <lisa.e.lippincott_at_[hidden]> wrote:
>
> On Oct 20, 2025, at 12:53 PM, John Spicer <jhs_at_[hidden]> wrote:
>>
>> This is not even remotely true.
>>
>> In most implementations weak linking is used for all inline functions where the implementation chooses not to inline, or in which a pointer to the function is taken.
>>
>> It is also used for all instantiation of functions.
>
> John, I feel like, in your haste, you have neglected to consider what I wrote carefully. (Or perhaps I am confused as to the referent of “this” in the first sentence, which I have taken to be the content of my earlier message.)
>
> I agree with your second and third sentences, which describe common practice. But where there is no possibility of pointer comparison, it is not a practice required by the standard or by any ABI with which I am familiar. Compilers often choose to use weak linking because it is seen as an optimization. They remain free to eschew weak linking in these cases, and they remain free to choose the symbol names to which they weakly link.
>
> In fact, our recent experience with GCC reminds us that weak linking inhibits other optimizations, and I would not be surprised to find that a less promiscuous application of weak linking would provide a desirable optimization for some programs.
>
> There are many ways to use weak linking in a less promiscuous way without completely eliminating its advantages. To pick an extreme example, a compiler may, acting unilaterally, weakly link a direct function call to a symbol name that encodes a hash of the compiler’s intended code. Doing so would increase code size only when different translation units produce different code for the same function, or when a different compiler is used. In return, the compiler gains insight into the unspecified aspects of the function’s behavior, and can use that information to optimize code surrounding the call.
>
> Would that be an improvement? It might be; I don’t know. But it is an allowed implementation technique.
>
> —Lisa
>
>
>>
>> John.
>>
>>
>>
>>> On Oct 20, 2025, at 3:39 PM, Lisa Lippincott <lisa.e.lippincott_at_[hidden]> wrote:
>>>
>>>
>>>> On Oct 20, 2025, at 8:52 AM, John Spicer via SG21 <sg21_at_[hidden]> wrote:
>>>>
>>>> The problem is that the language does not provide a way to allow people to protect themselves from this situation. I would not say it is mistake because it could involve libraries written by people that have never met one another.
>>>>
>>>> IMO, it *should* be possible to lock down a semantic to a function or a “component” but it is not possible with P2900, so you have a feature with very sharp edges that are hard for people to understand.
>>>
>>>
>>> I think you may be overlooking the fact that, in almost all* usage, weak linking is an optimization technique, not a requirement. If users are clamoring for weak linking to be limited in some way, implementations are free to respond. An implementation that limits its use of weak linking may be easier for some users to understand, and may also provide inter-procedural optimizations that are unavailable when using weak linking.
>>>
>>> In P2900, we chose to continue to make allowances allow for weak linking, and that does have an effect on the design. But we did nothing to require weak linking where there was no requirement before; it’s still largely optional.
>>>
>>>
>>> *In the one situation where weak linking is essentially required — comparison of pointers to nonmember functions defined in more than one translation unit — my understanding is that some implementations, particularly those using dynamic linking, are routinely nonconforming anyway. IMHO, we would be better off relaxing the pointer comparison rules, but I’m not planning to write that paper.
>>>
>>> —Lisa
>>>
>>
>
Received on 2025-10-21 16:59:30