[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