There's a new jump threader in GCC which is much more aggressive, and may trigger latent problems with other warning passes, especially -Warray-bounds, -Woverflow, and -Wuninitialized.
Do your problems go away if you take out commit 2e96b5f14e? I have notes throughout the commit analyzing variants of the above warnings (for example my addendum to gcc.c-torture/compile/pr83510.c). So far, all the warnings I've seen are legitimate jump threading opportunities that we are now doing, but which throw off the warning passes. Before the inclusion of the new threader, I had warned that this could happen. Perhaps we'll have to come up a way to reduce the false positives. Aldy On Fri, Jul 30, 2021 at 5:31 PM Joseph Myers <jos...@codesourcery.com> wrote: > > There are a lot of failures building glibc with mainline GCC right now > <https://sourceware.org/pipermail/libc-testresults/2021q3/008335.html> > (previously, there were ICEs building glibc on various architectures, so > these might be hard to bisect): > > > * x86_64-linux-gnu: "error: array subscript 0 is outside array bounds of > '__seg_fs struct pthread * __seg_fs[0]' [-Werror=array-bounds]". This is > the one discussed in > <https://gcc.gnu.org/pipermail/gcc/2021-July/236922.html>. > > In file included from ../sysdeps/generic/libc-tsd.h:44, > from ../include/../locale/localeinfo.h:224, > from ../include/ctype.h:26, > from loadmsgcat.c:29: > loadmsgcat.c: In function '_nl_load_domain': > ../sysdeps/x86_64/nptl/tls.h:185:4: error: array subscript 0 is outside array > bounds of '__seg_fs struct pthread * __seg_fs[0]' [-Werror=array-bounds] > 185 | (*(struct pthread *__seg_fs *) offsetof (struct pthread, > header.self)) > | > ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ../sysdeps/nptl/libc-lock.h:92:18: note: in expansion of macro 'THREAD_SELF' > 92 | void *self = THREAD_SELF; > \ > | ^~~~~~~~~~~ > loadmsgcat.c:770:3: note: in expansion of macro '__libc_lock_lock_recursive' > 770 | __libc_lock_lock_recursive (lock); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~ > > > * i686-gnu: > > hurdselect.c: In function '_hurd_select': > hurdselect.c:555:7: error: 'ss' may be used uninitialized in this function > [-Werror=maybe-uninitialized] > 555 | _hurd_sigstate_unlock (ss); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~ > > As far as I can tell, this is a false positive from the compiler (this > code is only reached if (sigport != MACH_PORT_NULL), in which case ss has > been initialized). > > > * Several architectures (all of them 32-bit), powerpc-linux-gnu for > example: > > In file included from t.61.c:437: > In function 'from_t_61_single', > inlined from 'gconv' at ../iconv/skeleton.c:568:15: > ../iconv/loop.c:440:22: error: writing 1 byte into a region of size 0 > [-Werror=stringop-overflow=] > 440 | bytebuf[inlen++] = *inptr++; > | ~~~~~~~~~~~~~~~~~^~~~~~~~~~ > ../iconv/loop.c: In function 'gconv': > ../iconv/loop.c:382:17: note: at offset 2 into destination object 'bytebuf' > of size 2 > 382 | unsigned char bytebuf[MAX_NEEDED_INPUT]; > | ^~~~~~~ > > I don't know if this is a false positive or not. > > > * powerpc64-linux-gnu: > > In file included from ../sysdeps/powerpc/dl-tls.c:20: > In function '_dl_allocate_tls_init', > inlined from '_dl_allocate_tls' at ../elf/dl-tls.c:621:10: > ../elf/dl-tls.c:529:10: error: array subscript -1 is outside array bounds of > 'void[9223372036854775807]' [-Werror=array-bounds] > 529 | dtv_t *dtv = GET_DTV (result); > | ^~~ > In file included from ../elf/dl-tls.c:28, > from ../sysdeps/powerpc/dl-tls.c:20: > ../sysdeps/powerpc/nptl/tls.h:136:34: error: array subscript -1 is outside > array bounds of 'void[9223372036854775807]' [-Werror=array-bounds] > 136 | ((tcbhead_t *) (tcbp))[-1].dtv = dtvp + 1 > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~ > ../elf/dl-tls.c:544:7: note: in expansion of macro 'INSTALL_DTV' > 544 | INSTALL_DTV (result, &dtv[-1]); > | ^~~~~~~~~~~ > > > * powerpc64le-linux-gnu: "error: '-mabi=ibmlongdouble' requires > '-mlong-double-128'". See > <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100909>. > > > -- > Joseph S. Myers > jos...@codesourcery.com >
