[llvm-dev] [RFH] "cannot apply asm label to function after its first use" on sparc64

Harald van Dijk via llvm-dev llvm-dev at lists.llvm.org
Wed Mar 10 10:06:19 PST 2021


Hi,

On 10/03/2021 12:13, John Paul Adrian Glaubitz via llvm-dev wrote:
> /usr/include/bits/stdio-ldbl.h:26:20: error: cannot apply asm label to function after its first use
> __LDBL_REDIR_DECL (vfprintf)
> ~~~~~~~~~~~~~~~~~~~^~~~~~~~~
> /usr/include/sys/cdefs.h:467:26: note: expanded from macro '__LDBL_REDIR_DECL'
>    extern __typeof (name) name __asm (__ASMNAME ("__nldbl_" #name));
>                           ^           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 1 error generated.
> 
> Does anyone have any idea what this error message actually means?

This error message means you cannot use the asm keyword to change how 
the function is named in the generated assembly after you have already 
done something that relies on that name. For instance:

   void f();
   void g() { f(); }
   void f() asm("h"); // Bad!

Here, as soon as the compiler has seen that g calls f, the external name 
for f is locked in, it can no longer be changed. However:

   void f();
   void f() asm("h"); // Ok!
   void g() { f(); }

Here, although there was a previous declaration of f without the asm 
keyword, f has not yet been used, nothing has been done that relies on 
its external name, and as such its external name may still be modified.

The line marked "Bad!" is accepted by GCC, but clang is intentionally 
incompatible with GCC here based on the assumption that glibc does not 
use this pattern and no one else should either, see bug 22830. It looks 
like that assumption is wrong, glibc does use this pattern (still? 
again?) for some targets, so if it is the intention that glibc does not, 
this will probably need to be fixed there.

FWIW, with test.c nothing more than #include <stdio.h>:

clang -c test.c -O -D__LONG_DOUBLE_MATH_OPTIONAL -D__NO_LONG_DOUBLE_MATH

produces the same error on Ubuntu x86-64 with libc6-dev 2.32-0ubuntu3. 
This is not actually a valid configuration, but may be good enough to 
make the problem easier to track down.

Cheers,
Harald van Dijk


More information about the llvm-dev mailing list