Bug 2115752 - glibc: ldbl redirects for wchar.h are incompatible with clang
Summary: glibc: ldbl redirects for wchar.h are incompatible with clang
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Carlos O'Donell
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: PPCTracker
TreeView+ depends on / blocked
 
Reported: 2022-08-05 09:25 UTC by Nikita Popov
Modified: 2022-10-25 13:42 UTC (History)
19 users (show)

Fixed In Version: glibc-2.36.9000-4.fc38
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-10-25 13:42:31 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Nikita Popov 2022-08-05 09:25:48 UTC
This is basically the same issue as https://bugzilla.redhat.com/show_bug.cgi?id=2100546, but for wchar.h. Seeing this build failure building clang with clang on ppc64le:

In file included from /builddir/build/BUILD/clang-15.0.0rc1.src/lib/Testing/CommandLineArgs.cpp:9:
In file included from /builddir/build/BUILD/clang-15.0.0rc1.src/include/clang/Testing/CommandLineArgs.h:16:
In file included from /builddir/build/BUILD/clang-15.0.0rc1.src/include/clang/Basic/LLVM.h:21:
In file included from /usr/include/llvm/Support/Casting.h:17:
In file included from /usr/include/llvm/ADT/Optional.h:19:
In file included from /usr/include/llvm/ADT/Hashing.h:54:
In file included from /usr/bin/../lib/gcc/ppc64le-redhat-linux/12/../../../../include/c++/12/string:40:
In file included from /usr/bin/../lib/gcc/ppc64le-redhat-linux/12/../../../../include/c++/12/bits/char_traits.h:39:
In file included from /usr/bin/../lib/gcc/ppc64le-redhat-linux/12/../../../../include/c++/12/bits/postypes.h:40:
In file included from /usr/bin/../lib/gcc/ppc64le-redhat-linux/12/../../../../include/c++/12/cwchar:44:
In file included from /usr/include/wchar.h:872:
/usr/include/bits/wchar-ldbl.h:84:1: error: cannot apply asm label to function after its first use
__LDBL_REDIR2_DECL (vswprintf_chk)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/sys/cdefs.h:573:30: note: expanded from macro '__LDBL_REDIR2_DECL'
  extern __typeof (__##name) __##name \
                             ^
<scratch space>:108:1: note: expanded from here
__vswprintf_chk
^

wchar.h includes wchar2.h which uses __vswprintf_chk and afterwards includes wchar-ldbl.h, which adds the asm label. Clang doesn't support this.

I'll confirm a minimal reproducer once I have provisioned a ppc64le machine, but I expect it's as simple as including wchar.h with clang -mabi=ieeelongdouble.

Comment 1 Nikita Popov 2022-08-05 09:56:32 UTC
Minimal reproducer on rawhide ppc64le:

dnf install clang
echo "#include <wchar.h>" > test.c
clang -mabi=ieeelongdouble -O2 -D_FORTIFY_SOURCE=1 test.c

Results in:

In file included from test.c:1:
In file included from /usr/include/wchar.h:872:
/usr/include/bits/wchar-ldbl.h:84:1: error: cannot apply asm label to function after its first use
__LDBL_REDIR2_DECL (vswprintf_chk)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/sys/cdefs.h:573:30: note: expanded from macro '__LDBL_REDIR2_DECL'
  extern __typeof (__##name) __##name \
                             ^
<scratch space>:179:1: note: expanded from here
__vswprintf_chk
^
1 error generated.

Comment 3 Ben Cotton 2022-08-09 13:35:51 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle.
Changing version to 37.

Comment 5 Carlos O'Donell 2022-08-23 13:25:16 UTC
We have discussed this issue with upstream glibc developers and there is a fix in progress here for wchar.h.

Comment 6 Raphael M Zinsly 2022-08-30 16:13:12 UTC
Fix commited to glibc as c7509d49c4e8fa494120c5ead21338559dad16f5

Comment 7 Dan Horák 2022-09-06 12:55:53 UTC
and included in glibc-2.36.9000-4.fc38

clang maintainers, please try the float128 switch again, thanks :-)

Comment 8 Carlos O'Donell 2022-09-06 13:34:06 UTC
This was fixed on August 30th for Fedora Rawhide with glibc-2.36.9000-4.fc38.

We will need this fix in Fedora 37, 36, 35, and 34.

We are working on correcting this in the other releases.

Comment 9 Dan Horák 2022-09-06 13:55:28 UTC
As the ABI change went into F-36, do we need the fix in the earlier releases? BTW F-34 has been EOL for a while.

Comment 10 Fedora Update System 2022-09-14 10:55:50 UTC
FEDORA-2022-e56ad56579 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-e56ad56579

Comment 11 Fedora Update System 2022-09-15 01:48:38 UTC
FEDORA-2022-e56ad56579 has been pushed to the Fedora 37 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-e56ad56579`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-e56ad56579

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 12 Fedora Update System 2022-09-19 00:18:52 UTC
FEDORA-2022-e56ad56579 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 13 Nikita Popov 2022-09-19 16:09:59 UTC
Thanks everyone! I gave this a try on rawhide and this issue is resolved now. Unfortunately, it looks like there are still other problems when using clang with -mabi=ieeelongdouble :(

> cat test.c
#include <stdio.h>
void test(const char *fmt, va_list ap) {
	vprintf(fmt, ap);
}

> clang -mabi=ieeelongdouble -O2 -D_FORTIFY_SOURCE=2 test.c
/usr/bin/ld: /usr/bin/../lib/gcc/ppc64le-redhat-linux/12/../../../../lib64/Scrt1.o:(.data.rel.ro.local+0x8): undefined reference to `main'
/usr/bin/ld: /tmp/test-0277a6.o: in function `test':
test.c:(.text+0x14): undefined reference to `vprintf.inline'
clang-15: error: linker command failed with exit code 1 (use -v to see invocation)

I don't know yet whether this indicates an issue on the clang or glibc side (but I suspect clang).

Comment 14 Siddhesh Poyarekar 2022-09-20 13:29:39 UTC
(In reply to Nikita Popov from comment #13)
> Thanks everyone! I gave this a try on rawhide and this issue is resolved
> now. Unfortunately, it looks like there are still other problems when using
> clang with -mabi=ieeelongdouble :(

I'll take a look at this.

Comment 15 Nikita Popov 2022-09-20 13:42:59 UTC
There's a reduction of the issue here: https://gist.github.com/nikic/707b43c9479b40dba3e26d4d03a7beeb

Based on initial analysis, this is a bug in clang's handling of "builtin inline functions" in conjunction with asm labels, which Serge is going to look into. So I think this doesn't need action from the glibc side for now.

Comment 16 Siddhesh Poyarekar 2022-09-21 12:56:30 UTC
I agree, this doesn't look like a glibc issue.  The asm label:

extern __typeof (vprintf) vprintf __asm ("" "__" "vprintf" "ieee128");

seems to prevent the fortified function from being inlined, resulting in the vprintf.inline call.  This should probably be a separate bug since it's unrelated to this one.

Comment 17 serge_sans_paille 2022-09-21 14:33:34 UTC
Upstream patch: https://reviews.llvm.org/D134362

Comment 18 Carlos O'Donell 2022-10-25 13:42:31 UTC
I'm going to consider this closed from the glibc side since the headers are fixed and the remaining issues will be fixed in clang.

Marked CLOSED RAWHIDE. Thank you!


Note You need to log in before you can comment on or make changes to this bug.