After this patch [1], I am seeing this -Warray-parameter error when building gcc: In file included from ../include/pthread.h:1, from ../sysdeps/nptl/thread_db.h:25, from ../nptl/descr.h:32, from ../sysdeps/aarch64/nptl/tls.h:44, from ../include/errno.h:25, from ../sysdeps/unix/sysv/linux/sysdep.h:23, from ../sysdeps/unix/sysv/linux/generic/sysdep.h:22, from ../sysdeps/unix/sysv/linux/aarch64/sysdep.h:24, from <stdin>:1: ../sysdeps/nptl/pthread.h:734:47: error: argument 1 of type ‘struct __jmp_buf_tag *’ declared as a pointer [-Werror=array-parameter=] 734 | extern int __sigsetjmp (struct __jmp_buf_tag *__env, int __savemask) __THROWNL; | ~~~~~~~~~~~~~~~~~~~~~~^~~~~ In file included from ../include/setjmp.h:2, from ../nptl/descr.h:24, from ../sysdeps/aarch64/nptl/tls.h:44, from ../include/errno.h:25, from ../sysdeps/unix/sysv/linux/sysdep.h:23, from ../sysdeps/unix/sysv/linux/generic/sysdep.h:22, from ../sysdeps/unix/sysv/linux/aarch64/sysdep.h:24, from <stdin>:1: ../setjmp/setjmp.h:54:46: note: previously declared as an array ‘struct __jmp_buf_tag[1]’ 54 | extern int __sigsetjmp (struct __jmp_buf_tag __env[1], int __savemask) __THROWNL; | ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~ cc1: all warnings being treated as errors The build/host/target setup is: Build: x86_64-linux-gnu (Ubuntu 18.04) Host: x86_64-linux-gnu Target: aarch64-none-linux-gnu, aarch64_be-none-linux-gnu, arm-none-linux-gnueabi, arm-none-linux-gnueabihf This was mentioned in https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554415.html and it seems like the warning might need to be suppressed in glibc. [1] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=6450f07388f9fe575a489c9309c36012b17b88b0
I also noticed this when building natively on ppc64le. It doesn't seem to be target-specific. I experimented adjusting the __sigsetjmp declaration in sysdeps/nptl/pthread.h to match the one in setjmp/setjmp.h, but then it led to other failure: ../csu/libc-start.c: In function ‘generic_start_main.isra’: ../setjmp/setjmp.h:62:25: error: ‘_setjmp’ accessing 656 bytes in a region of size 528 [-Werror=stringop-overflow=] 62 | #define setjmp(env) _setjmp (env) | ^~~~~~~~~~~~~ ../csu/libc-start.c:301:20: note: in expansion of macro ‘setjmp’ 301 | not_first_call = setjmp ((struct __jmp_buf_tag *) unwind_buf.cancel_jmp_buf); | ^~~~~~ ../setjmp/setjmp.h:62:25: note: referencing argument 1 of type ‘struct __jmp_buf_tag *’ 62 | #define setjmp(env) _setjmp (env) | ^~~~~~~~~~~~~ ../csu/libc-start.c:301:20: note: in expansion of macro ‘setjmp’ 301 | not_first_call = setjmp ((struct __jmp_buf_tag *) unwind_buf.cancel_jmp_buf); | ^~~~~~ cancel_jmp_buf is defined in nptl/descr.h as: struct pthread_unwind_buf { struct { __jmp_buf jmp_buf; int mask_was_saved; } cancel_jmp_buf[1]; <...> } On the line causing the warning above, the field is cast to 'struct __jmp_buf_tag *' and passed to setjmp. But this last struct has an extra field that cancel_jmp_buf doesn't: struct __jmp_buf_tag { /* NOTE: The machine-dependent definitions of `__sigsetjmp' assume that a `jmp_buf' begins with a `__jmp_buf' and that `__mask_was_saved' follows it. Do not move these members or add others before it. */ __jmp_buf __jmpbuf; /* Calling environment. */ int __mask_was_saved; /* Saved the signal mask? */ __sigset_t __saved_mask; /* Saved signal mask. */ <------- }; Could this be an actual invalid access and not just a false-positive after all or was this by design?
This depends on the fact that _setjmp never saves the signal mask and thus never accesses the __saved_mask field (and neither does longjmp).
The master branch has been updated by Joseph Myers <jsm28@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=19302b27bdacfe87e861ff46fc0fbad60dd6602d commit 19302b27bdacfe87e861ff46fc0fbad60dd6602d Author: Joseph Myers <joseph@codesourcery.com> Date: Mon Oct 5 16:46:46 2020 +0000 Fix GCC 11 -Warray-parameter warning for __sigsetjmp (bug 26647) This patch fixes part of bug 26647 (-Werror=array-parameter error building with GCC 11 because of __sigsetjmp being declared using an array parameter in one header and a pointer parameter in another). The fix is to split the struct __jmp_buf_tag definition out to a separate bits/types/ header so it can be included in pthread.h, so that pthread.h can declare __sigsetjmp with the type contents visible, so can use an array (as in setjmp.h) rather than a pointer in the declaration. Note that several other build failures with GCC 11 remain. This does not fix the jmp_buf-related -Wstringop-overflow errors (also discussed in bug 26647), or -Warray-parameter errors for other functions (bug 26686), or -Warray-bounds errors (bug 26687). Tested, with older compilers, natively for x86_64 and with build-many-glibc.py for aarch64-linux-gnu. Tested with build-many-glibcs.py with GCC mainline for aarch64-linux-gnu that this gets past the -Warray-parameter issue for __sigsetjmp (with the next build failure being the other one discussed in bug 26647).
*** Bug 26709 has been marked as a duplicate of this bug. ***
*** Bug 26750 has been marked as a duplicate of this bug. ***
*** Bug 26789 has been marked as a duplicate of this bug. ***
The master branch has been updated by Joseph Myers <jsm28@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=2098d4034d398cbde6ccd4a2aaac52c518374698 commit 2098d4034d398cbde6ccd4a2aaac52c518374698 Author: Joseph Myers <joseph@codesourcery.com> Date: Fri Oct 30 21:38:31 2020 +0000 Disable spurious -Wstringop-overflow for setjmp/longjmp (bug 26647) Building glibc with GCC 11 fails with (among other warnings) spurious -Wstringop-overflow warnings from calls to setjmp and longjmp with a pointer to a pthread_unwind_buf that is smaller than jmp_buf. As discussed in bug 26647, the warning in libc-start.c is a false positive, because setjmp and longjmp do not access anything (the signal mask) beyond the common prefix of the two structures, so this patch disables the warning for that call to setjmp, as well as for two calls in NPTL code that produce the same warning and look like false positives for the same reason. Tested with build-many-glibcs.py for arm-linux-gnueabi, where this allows the build to get further. Reviewed-by: DJ Delorie <dj@redhat.com>
Fixed for 2.33.
The same error can occur with pthread_cleanup_push (https://gitlab.com/qemu-project/qemu/-/issues/400). Is it possible to include the appropriate _Pragmas in the macro as well?