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).