[PING PATCH] document that alias and target must have the same type

[Martin Sebor <msebor@gmail.com>]

Ping: https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00290.html

On 2/5/20 1:13 PM, Martin Sebor wrote:
> On 2/4/20 6:05 PM, Martin Sebor wrote:
>> GCC diagnoses declarations of function aliases whose type doesn't
>> match that of the target (ditto for attribute weakref).  It doesn't
>> yet diagnose such incompatbilities for variable aliases but that's
>> just an oversight that I will try to remember to correct in GCC 11.
>> The attached patch updates the manual to make it clear that
>> aliases must have the same type as their targets, or the behavior
>> is undefined (and may be diagnosed).
> 
> On further review I noticed a few problems with the documentation
> of attribute weakref.  The manual says that
> 
>    Without a target, given as an argument to weakref or to alias,
>    weakref is equivalent to weak.
> 
> and
> 
>    At present, a declaration to which weakref is attached can only
>    be static.
> 
> However, GCC accepts the following declaration:
> 
>    extern int x (void) __attribute__ ((weakref));
> 
> so the second sentence isn't correct without qualification (unlike
> weakref, a weak declaration must be external).
> 
> Another documentation problem is with the example in the manual that
> says that this declaration:
> 
>    static int x() __attribute__ ((weakref ("y")));
> 
>    /* is equivalent to... */
> 
>    static int x() __attribute__ ((weak, weakref, alias ("y")));
> 
> but GCC rejects the latter with
> 
>    error: weak declaration of ‘x’ must be public
> 
> Changing the latter from static to extern changes the error to
> 
>    error: ‘weakref’ symbol ‘x’ must have static linkage
> 
> So clearly two declarations with the two sets of attributes are not
> equivalent, either extern or static.
> 
> I've fixed up these documentation problems in the attached revision
> of the original patch.  I also mention that besides their types
> having to match, the alias must have the same size and alignment
> as the target.
> 
> Martin
> 
> PS I also noted that when the function is then also used GCC issues:
> 
>    warning: ‘weakref’ attribute should be accompanied with an ‘alias’ 
> attribute
> 
> This matches what the manual says in "Without arguments, it should
> be accompanied by an alias attribute naming the target symbol."
> 
> But when the weakref function is not used there is no warning.
> That seems like an unfortunate side-effect of the choice of issuing
> the warning a little too late (waning from the front-end it would
> make it consistent regardless of whether the function was used, and
> it would highlight the omission even in translation units that
> define the weakref without using it).