[RFC] gcc 4.8 vs glibc alias macros

[Richard Henderson]

Dunno if alpha is going to be the only glibc port to encounter this, if it should be considered a gcc bug, or what.

Without this patch, using mainline gcc, I get

./../include/libc-symbols.h:485:26: error: ‘__EI___isnanf’ aliased to external symbol ‘__GI___isnanf’
   extern __typeof (name) __EI_##name \
                          ^
./../include/libc-symbols.h:489:29: note: in expansion of macro '__hidden_ver1'
 #  define hidden_def(name)  __hidden_ver1(__GI_##name, name, name);
                             ^
../ports/sysdeps/alpha/fpu/s_isnan.c:48:1: note: in expansion of macro 'hidden_def'
 hidden_def (__isnanf)
 ^

We get this because I chained aliases from __isnan to __isnanf to __GI___isnanf.

The patch works around this by defining both __isnanf and __GI___isnanf in terms of the original __isnan.

This isn't 100% correct since the __GI___isnanf symbol gets defined in the object file with visibility default, but it doesn't matter in practice because the users of the symbol still see the hidden_proto and so when the symbols are merged in the linker and link map applied, it acquires hidden visibility.

I'm looking for opinions as to whether (1) this is a gcc bug and (2) whether the patch should be applied to glibc regardless.



r~
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-alpha-Work-around-gcc-4.8-aliasing-difference-bug.patch
Type: text/x-patch
Size: 1648 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20120830/5556422d/attachment.bin>