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