[PATCH] Fix gcc.dg/attr-weak-hidden-1{,a}.c

[Richard Sandiford]

Richard Guenther <richard.guenther@gmail.com> writes:
> On Mon, Feb 21, 2011 at 1:10 PM, Richard Sandiford
> <rdsandiford@googlemail.com> wrote:
>> Richard Guenther <richard.guenther@gmail.com> writes:
>>>>> I am not even sure that the linking result is well-defined just by
>>>>> the linking order on the linker command-line.  Does ELF symbol
>>>>> resolution as specced even have such?
>>>>
>>>> I suppose link-line order isn't really an ELF-level thing.  It is
>>>> guaranteed by GNU ld, and by other linkers I've used (admittedly a
>>>> relatively small set).  It's not that unusual for the weakness of
>>>> a symbol to be defined in a header file -- that's how you typically
>>>> get undefined weak symbols.
>>>
>>> Sure, but that's unrelated to this case where you have two semantically
>>> different weak definitions, not undefined weak symbols.
>>
>> What I said was related.  What I meant was: it's not uncommon for
>> weakness to be defined in the header file.  It's also not uncommon for
>> .c files that define a function to include a .h that declares the
>> function.  If you combine those two approaches for a function with two
>> possible definitions _within the same package_ (as was the case with the
>> original bug), then both definitions will be weak definitions, as here.
>
> Right, but in 99% (or even more) of all cases they are semantically equivalent
> and thus linking order doesn't matter.

Really?  In most of the uses of "weak" that I've seen, the user really
does care which definition gets picked.

Richard