GCC 11 has enhanced -Wmaybe-uninitialized to trigger when the address of an uninitialized object is passed to a const pointer function parameter. The assumption is that the function will most likely read the referenced object. As a result, when compiled with GCC 11, code that passes such an address to pthread_setspecific() such as the test case below triggers the warning. This has caused the following failure in GCC https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99984. $ cat z.c && gcc -S -Wall z.c #include <pthread.h> void f (pthread_key_t key) { int x; pthread_setspecific (key, &x); } z.c: In function ‘f’: z.c:6:3: warning: ‘x’ may be used uninitialized [-Wmaybe-uninitialized] 6 | pthread_setspecific (key, &x); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from z.c:1: /usr/include/pthread.h:1123:12: note: by argument 2 of type ‘const void *’ to ‘pthread_setspecific’ declared here 1123 | extern int pthread_setspecific (pthread_key_t __key, | ^~~~~~~~~~~~~~~~~~~ z.c:5:7: note: ‘x’ declared here 5 | int x; | ^ (The same warning is triggered when the result of malloc() is passed to the function.) To avoid the warning in calls to functions like pthread_setspecific that don't read the object GCC 11 also extends attribute access to accept a new mode: none. Glibc should make use of the attribute in the declaration of the function (and any others like it).
Patch: https://sourceware.org/pipermail/libc-alpha/2021-April/125358.html
Fixed in https://sourceware.org/pipermail/glibc-cvs/2021q2/072962.html.
With GCC 11, now I got tst-tsd3.c: In function ‘tf’: tst-tsd3.c:71:7: error: ‘pthread_setspecific’ expecting 1 byte in a region of size 0 [-Werror=stringop-overread] 71 | if (pthread_setspecific (key1, (void *) 1l) != 0 | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from ../include/pthread.h:1, from tst-tsd3.c:20: ../sysdeps/nptl/pthread.h:1184:12: note: in a call to function ‘pthread_setspecific’ declared with attribute ‘access (none, 2)’ 1184 | extern int pthread_setspecific (pthread_key_t __key, | ^~~~~~~~~~~~~~~~~~~ tst-tsd3.c:72:10: error: ‘pthread_setspecific’ expecting 1 byte in a region of size 0 [-Werror=stringop-overread] 72 | || pthread_setspecific (key2, (void *) 1l) != 0) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from ../include/pthread.h:1, from tst-tsd3.c:20: ../sysdeps/nptl/pthread.h:1184:12: note: in a call to function ‘pthread_setspecific’ declared with attribute ‘access (none, 2)’ 1184 | extern int pthread_setspecific (pthread_key_t __key, | ^~~~~~~~~~~~~~~~~~~ tst-tsd3.c: In function ‘destr2’: tst-tsd3.c:56:11: error: ‘pthread_setspecific’ expecting 1 byte in a region of size 0 [-Werror=stringop-overread] 56 | if (pthread_setspecific (key1, (void *) 1l) != 0) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from ../include/pthread.h:1, from tst-tsd3.c:20: ../sysdeps/nptl/pthread.h:1184:12: note: in a call to function ‘pthread_setspecific’ declared with attribute ‘access (none, 2)’ 1184 | extern int pthread_setspecific (pthread_key_t __key, | ^~~~~~~~~~~~~~~~~~~ tst-tsd3.c: In function ‘destr1’: tst-tsd3.c:40:11: error: ‘pthread_setspecific’ expecting 1 byte in a region of size 0 [-Werror=stringop-overread] 40 | if (pthread_setspecific (key2, (void *) 1l) != 0) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from ../include/pthread.h:1, from tst-tsd3.c:20: ../sysdeps/nptl/pthread.h:1184:12: note: in a call to function ‘pthread_setspecific’ declared with attribute ‘access (none, 2)’ 1184 | extern int pthread_setspecific (pthread_key_t __key, | ^~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[4]: *** [../o-iterator.mk:9: /export/build/gnu/tools-build/glibc-lam-test/build-x86_64-linux/nptl/tst-tsd3.o] Error 1
All those warnings should be fixed as of last night: https://sourceware.org/pipermail/glibc-cvs/2021q2/072963.html If any are not, please open a new bug.
(In reply to Martin Sebor from comment #4) > All those warnings should be fixed as of last night: > https://sourceware.org/pipermail/glibc-cvs/2021q2/072963.html > If any are not, please open a new bug. You may have fixed the warnings in gcc but now everyone downstream has to deal with pthread_setspecific requiring a valid pointer to memory where it did not require that before.