Bug 2068692
| Summary: | glibc: ppc64le error-ldbl.h does not provide noreturn/return cases for error function. | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Mark Wielaard <mjw> |
| Component: | glibc | Assignee: | Arjun Shankar <ashankar> |
| Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | aoliva, arjun, codonell, dj, fweimer, law, mcermak, mfabian, pfrankli, rth, sipoyare |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-04-12 13:24:30 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Note for elfutils I created the following workaround: https://sourceware.org/pipermail/elfutils-devel/2022q1/004814.html In misc/bits/error.h we took care of this properly in the glibc sources:
34 /* If we know the function will never return make sure the compiler
35 realizes that, too. */
36 __extern_always_inline void
37 error (int __status, int __errnum, const char *__format, ...)
38 {
39 if (__builtin_constant_p (__status) && __status != 0)
40 __error_noreturn (__status, __errnum, __format, __va_arg_pack ());
41 else
42 __error_alias (__status, __errnum, __format, __va_arg_pack ());
43 }
44
We have two paths. One path for the __error_noreturn case when __status is non-zero. And the returning __error_alias case when __status is zero.
However misc/bits/error-ldbl.h doesn't have any of the inline function pieces to provide the same behaviour.
This is caused by the IEEE 128-bit long double switch. This is an upstream bug (we should file an upstream bug).
I filed this upstream. This bug is being tracked upstream here: https://sourceware.org/bugzilla/show_bug.cgi?id=29033 We are going to raise this with IBM to fix upstream. I am marking this closed upstream. When upstream gets fixed we can backport a fix. |
The combination of gcc (gcc-12.0.1-0.12.fc36.ppc64le) and glibc (glibc-2.35-2.fc36.ppc64le) produces bad warnings/errors when error (EXIT_FAILURE, ...) is used on ppc64le (every other architecture is fine). Take the following program: $ cat w.c #include <error.h> #include <stddef.h> #include <stdlib.h> struct S { int i; }; int main (int argc, char **argv) { struct S ss; struct S *s = argv[argc - 1] == NULL ? &ss : NULL; if (s == NULL) error (EXIT_FAILURE, 0, "frob"); if (s->i == 0) return 1; return 0; } Which compiles just fine on any architecture except ppc64le where it produces: $ gcc -Wnull-dereference -Werror -O2 -g w.c w.c: In function ‘main’: w.c:18:8: error: potential null pointer dereference [-Werror=null-dereference] 18 | if (s->i == 0) | ~^~~ cc1: all warnings being treated as errors The warning is incorrect is because error (EXIT_FAILURE, ...) doesn't return, which makes sure s is never dereferenced when it is NULL. Except on ppc64le on f36.