Reproducer: --- #include <stdio.h> int main() { return 0; } --- Build: --- $ clang bug.c -o bug -O2 In file included from bla.c:1: In file included from /usr/include/stdio.h:899: /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:569:26: note: expanded from macro '__LDBL_REDIR_DECL' extern __typeof (name) name __asm (__ASMNAME ("__" #name "ieee128")); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. --- With GCC, it just works: --- $ gcc bug.c -o bug -O3 -Wall -Wextra --- Versions: --- $ rpm -q glibc-devel clang gcc glibc-devel-2.35.9000-22.fc37.ppc64le clang-14.0.0-4.fc37.ppc64le gcc-12.1.1-1.fc37.ppc64le ---
Python issue: https://github.com/python/cpython/issues/94178 Dan Horák wrote: > I believe this is a known issue between latest glibc and clang after we default to the ieee128 long double type.
This is a Clang vs GCC difference and more like a clang limiation.
Upstream patch (not yet committed): [PATCH] Apply asm redirections in stdio.h before first use [BZ #27087] <https://sourceware.org/pipermail/libc-alpha/2021-December/134212.html> I'm going to ping the author.
/usr/include/bits/stdio-ldbl.h at line 26: --- __LDBL_REDIR_DECL (vfprintf) --- /usr/include/sys/cdefs.h near line 569: --- #if __LDOUBLE_REDIRECTS_TO_FLOAT128_ABI == 1 # ifdef __REDIRECT (...) # define __LDBL_REDIR_DECL(name) \ extern __typeof (name) name __asm (__ASMNAME ("__" #name "ieee128")); --- /usr/include/bits/long-double.h defines __LDOUBLE_REDIRECTS_TO_FLOAT128_ABI macro as: --- #define __LDOUBLE_REDIRECTS_TO_FLOAT128_ABI (__LDBL_MANT_DIG__ == 113) --- In short, #include <sys/cdefs.h> is enough to define __LDOUBLE_REDIRECTS_TO_FLOAT128_ABI macro value as true (non-zero). It seems like glibc-devel-2.35.9000-1.fc37.ppc64le.rpm contained the same code. I don't know when glibc-devel-2.35.9000-22.fc37.ppc64le was installed on the ppc64le affected machine. Maybe it's a clang update. dnf.log says: "2022-06-23T07:02:51-0400 DEBUG Upgraded: clang-14.0.0-4.fc37.ppc64le".
This is now the only blocker for bz2025599 which itself blocks around a dozen other packages from rebuilding with Python 3.11. Please prioritize this.
https://koschei.fedoraproject.org/package/postgresql suggests this changed in https://koschei.fedoraproject.org/build/13101483 which contains clang update from 14.0.0-1.fc37 to 14.0.0-4.fc37.
Makes me think this broke with https://src.fedoraproject.org/rpms/clang/c/27327ff4a817d28b99c8175dcaaa7ddd4395b5a0?branch=rawhide
(In reply to Miro Hrončok from comment #6) > This is now the only blocker for bz2025599 which itself blocks around a > dozen other packages from rebuilding with Python 3.11. Please prioritize > this. How is this bug blocking the other bug? Wrong bug number? (In reply to Miro Hrončok from comment #8) > Makes me think this broke with > https://src.fedoraproject.org/rpms/clang/c/ > 27327ff4a817d28b99c8175dcaaa7ddd4395b5a0?branch=rawhide Yes, of course. The glibc headers are currently incompatible with Clang and long-double-as-ieee128.
(In reply to Florian Weimer from comment #9) > (In reply to Miro Hrončok from comment #6) > > This is now the only blocker for bz2025599 which itself blocks around a > > dozen other packages from rebuilding with Python 3.11. Please prioritize > > this. > > How is this bug blocking the other bug? Wrong bug number? The package needs to be rebuilt in order to be installable and it cannot be rebuilt because it FTBFS on power. Correct bug number. > (In reply to Miro Hrončok from comment #8) > > Makes me think this broke with > > https://src.fedoraproject.org/rpms/clang/c/ > > 27327ff4a817d28b99c8175dcaaa7ddd4395b5a0?branch=rawhide > > Yes, of course. The glibc headers are currently incompatible with Clang and > long-double-as-ieee128. In that case, I propose we revert that change in clang until this is fixed.
I wanted to test the revert in ppc64le-test.fedorainfracloud.org but there is not enough disc space to build PostgreSQL or python-pyside2 there. Trying in Copr now.
> In that case, I propose we revert that change in clang until this is fixed. I tested clang 14.0.5-2.fc37.ppc64le package built by Miro: sudo dnf install https://kojipkgs.fedoraproject.org//work/tasks/5733/88915733/clang{,-{libs,devel,resource-filesystem,tools-extra}}-14.0.5-2.fc37.ppc64le.rpm https://kojipkgs.fedoraproject.org//packages/compiler-rt/14.0.5/1.fc37/ppc64le/compiler-rt-14.0.5-1.fc37.ppc64le.rpm https://kojipkgs.fedoraproject.org//packages/libomp/14.0.5/1.fc37/ppc64le/libomp-devel-14.0.5-1.fc37.ppc64le.rpm Before: "#include <stdio.h> int main() { return 0; }" failed to build. After: with clang 14.0.5-2.fc37.ppc64le, the build succeed. The package reverts https://src.fedoraproject.org/rpms/clang/c/27327ff4a817d28b99c8175dcaaa7ddd4395b5a0?branch=rawhide if I understood correctly.
Yes, this was built from https://src.fedoraproject.org/rpms/clang/pull-request/170
I've created a scratch build and confirmed it fixes the issue: https://koji.fedoraproject.org/koji/taskinfo?taskID=88921107 Feedback is welcome! I'm submitting this upstream now.
The clang thing was reverted in clang-14.0.5-2.fc37 hence unblocked bz2025599 and lowering the severity. Leaving this open for two reasons. 1) clang-14.0.5-2.fc37 has not yet reached rawhide, it only exists in a side tag 2) to track the fix in glibc and un-revert the thing in clang.
Are you sure you know what you're doing? As far as I can see (not being an expert here), the change in clang is a reaction to a change in gcc (https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition), and reverting it will cause silent data corruption when passing long double between libraries built with gcc and ones built with clang.
> Are you sure you know what you're doing? Not at all. I've proposed to revert a change that caused a regression and the clang maintainers who understand this better than I merged it. As far as I know https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition happened a long time ago and the change in clang only happened quite recently. I assumed if we could have released Fedora 36 without it, we can wait couple more days before glibc is ready.
> I've created a scratch build and confirmed it fixes the issue: https://koji.fedoraproject.org/koji/taskinfo?taskID=88921107 Feedback is welcome! Great! Right now, I can no longer reproduce the issue, so sadly I cannot test this build :-(
> Right now, I can no longer reproduce the issue... You could run: sudo dnf distro-sync clang compiler-rt libomp-devel
> Not at all. I've proposed to revert a change that caused a regression and the clang maintainers who understand this better than I merged it. OK looks like the downsides are taken into account, and the alarm was unnecessary. Sorry for the noise!
*** Bug 2100833 has been marked as a duplicate of this bug. ***
(In reply to Petr Viktorin from comment #16) > Are you sure you know what you're doing? > As far as I can see (not being an expert here), the change in clang is a > reaction to a change in gcc > (https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition), and > reverting it will cause silent data corruption when passing long double > between libraries built with gcc and ones built with clang. You are correct reverting this could cause data corruption in some cases. However, we had this ABI mismatch between gcc and clang for a while and no one reported any issues, so I think we'll be OK temporarily.
(In reply to Tulio Magno Quites Machado Filho from comment #14) > I've created a scratch build and confirmed it fixes the issue: > https://koji.fedoraproject.org/koji/taskinfo?taskID=88921107 > Feedback is welcome! > > I'm submitting this upstream now. Thank you, I'll try to get this into Fedora 36 and rawhide early next week, independently of upstream status.
> I've created a scratch build and confirmed it fixes the issue: https://koji.fedoraproject.org/koji/taskinfo?taskID=88921107 Feedback is welcome! Great, it fix the issue! The updated glibc header files are compatible again with old clang. I downgraded clang to clang-14.0.5-1.fc37.ppc64le using https://koji.fedoraproject.org/koji/buildinfo?buildID=1984833 : I can reproduce the bug again. I upgraded glibc to https://koji.fedoraproject.org/koji/taskinfo?taskID=88921107 : with old clang (clang-14.0.5-1) and new glibc (glibc-2.35.9000-26), I can no longer reproduce the issue!
I've pushed Tulio's patch. I think there's currently a problem with the signing server, so I don't know when the new packages are going to make it into the repositories.
FEDORA-2022-1cbd5e821e has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-1cbd5e821e
FEDORA-2022-1cbd5e821e has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-1cbd5e821e` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-1cbd5e821e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-1cbd5e821e has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.