Bug 2115752

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.

This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle.
Changing version to 37.

We have discussed this issue with upstream glibc developers and there is a fix in progress here for wchar.h.

Fix commited to glibc as c7509d49c4e8fa494120c5ead21338559dad16f5

and included in glibc-2.36.9000-4.fc38

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

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.

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.

FEDORA-2022-e56ad56579 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-e56ad56579

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.

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.

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).

(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.

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.

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.

Upstream patch: https://reviews.llvm.org/D134362

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!