Program to re-produce: #include <stdio.h> int main(void) { return 0; } Use clang (I tried with latest build, but recent releases should be all fine) to compile this program with IEEE and optimization options: clang test.c -O3 -mabi=ieeelongdouble -I<HEADER_PATH> An error would happen: In file included from test.c:1: In file included from /opt/at14.0-1-rc1/include/stdio.h:871: /opt/at14.0-1-rc1/include/bits/stdio-ldbl.h:26:20: error: cannot apply asm label to function after its first use __LDBL_REDIR_DECL (vfprintf) ~~~~~~~~~~~~~~~~~~~^~~~~~~~~ /opt/at14.0-1-rc1/include/sys/cdefs.h:461:26: note: expanded from macro '__LDBL_REDIR_DECL' extern __typeof (name) name __asm (__ASMNAME ("__" #name "ieee128")); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Because under -O, clang (and gcc) defines macro `__USE_EXTERN_INLINES`. The part is located before #include <bits/stdio-ldbl.h> stuff, so compiler complains about the re-declaration conflict. Not sure why GCC is silent about this yet. By exchanging their position, the error would disappear. Discussion in clang community about changing this error to warning (https://reviews.llvm.org/D16171) may be a good reference.
A patch has been posted: [PATCH] Apply asm redirections in stdio.h before first use [BZ #27087] <https://sourceware.org/pipermail/libc-alpha/2021-December/134212.html>
I have some local patches that I need to polish to fix it for all definitions (there are on my azanella/clang branch [1]). I think we will need to adjust more function that Tulio's patch. [1] https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/azanella/clang
(In reply to Adhemerval Zanella from comment #2) > I have some local patches that I need to polish to fix it for all > definitions (there are on my azanella/clang branch [1]). I think we will > need to adjust more function that Tulio's patch. > > [1] > https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/azanella/ > clang My main concern is that this breaks the glibc headers on ppc64le, with clang defaulting to float128 support. It's not just an issue for building glibc with clang.
Version 2 of the patch sent to libc-alpha: https://sourceware.org/pipermail/libc-alpha/2022-June/140313.html
While the initial issue has been fixed in glibc 2.36 and backported to 2.35, wchar.h is still affected by this. See the report in https://bugzilla.redhat.com/show_bug.cgi?id=2115752
(In reply to Tulio Magno Quites Machado Filho from comment #5) > While the initial issue has been fixed in glibc 2.36 and backported to 2.35, > wchar.h is still affected by this. > See the report in https://bugzilla.redhat.com/show_bug.cgi?id=2115752 The wchar.h issue has been fixed by c7509d49c4e8fa494120c5ead21338559dad16f5 for glibc 2.37. A patch has been proposed for an error in syslog.h: https://patchwork.sourceware.org/project/glibc/patch/20221116150803.1990947-1-tuliom@ascii.art.br/
Fixed with the following commit for glibc 2.37: commit 227df6243a2b5b4d70d11772d12c02eb9cb666ca Author: Tulio Magno Quites Machado Filho <tuliom@redhat.com> Date: Fri Nov 11 17:00:15 2022 -0300 Apply asm redirections in syslog.h before first use [BZ #27087] Similar to d0fa09a770, but for syslog.h when _FORTIFY_SOURCE > 0. Fixes [BZ #27087] by applying long double-related asm redirections before using functions in bits/syslog.h. Tested with build-many-glibcs.py. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> I plan to backport this fix to glibc 2.34, 2.35 and 2.36.