Failures building glibc with mainline GCC

Failures building glibc with mainline GCC

[Joseph Myers]

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
joseph@codesourcery.com

Re: Failures building glibc with mainline GCC

[Aldy Hernandez via Libc-alpha]

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 <joseph@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
> joseph@codesourcery.com
>

Re: Failures building glibc with mainline GCC

[Jeff Law via Libc-alpha]

On 7/30/2021 10:19 AM, Aldy Hernandez via Libc-alpha wrote:
> 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.
I should be able to get you testcases for at least some of these.  I 
strongly suspect it's the new threader.  First up will be the iconf 
stringop-overflow failures which should hit your inbox shortly.

Jeff

Re: Failures building glibc with mainline GCC

[Joseph Myers]

In addition to failures building glibc, for those configurations for which 
glibc builds there's a failure building the testsuite:

tst-thread_local1.cc:177:5: error: variable 'std::array<std::pair<const char*, std::function<void(void* (*)(void*))> >, 2> do_thread_X' has initializer but incomplete type
  177 |     do_thread_X
      |     ^~~~~~~~~~~

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Failures building glibc with mainline GCC

[Jakub Jelinek via Libc-alpha]

On Fri, Jul 30, 2021 at 04:38:58PM +0000, Joseph Myers wrote:
> In addition to failures building glibc, for those configurations for which 
> glibc builds there's a failure building the testsuite:
> 
> tst-thread_local1.cc:177:5: error: variable 'std::array<std::pair<const char*, std::function<void(void* (*)(void*))> >, 2> do_thread_X' has initializer but incomplete type
>   177 |     do_thread_X
>       |     ^~~~~~~~~~~

This is likely a test bug, Jonathan has changed the libstdc++ headers like
many times already to include fewer includes for the internal implementation
details when the standard doesn't require everything or specific parts from
one header to appear whenever including another one.
Usually one needs to add new includes when this happens for whatever the
test is using.

	Jakub

Re: Failures building glibc with mainline GCC

[Jeff Law via Libc-alpha]

[-- Attachment #1: Type: text/plain, Size: 1264 bytes --]



On 7/30/2021 10:19 AM, Aldy Hernandez via Libc-alpha wrote:
> 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.
[ ... ]
Ugh.  First attempt got blocked as message was slightly too big.

I think this is pretty generic as I've seen it on multiple ports and 
Joseph mentioned them as well.

With an s390-linux-gnu (not s390x!) cross compiler you should be able to 
trigger:

bash-5.1# s390-linux-gnu-gcc -std=gnu99 -O2 -Wall -mlong-double-128 *.i
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: warning: writing 1 byte into a region of size 0 
[-Wstringop-overflow=]
In file included from t.61.c:437:
../iconv/loop.c: In function 'gconv':
../iconv/loop.c:382:17: note: at offset 2 into destination object 
'bytebuf' of size 2


I don't know if it's a real failure or a false positive.  I haven't even 
bisected, but I suspect the new threader is the triggering change.  
Ideally the threader threaded a path we hadn't previously and by some 
chain of events exposed a out of bounds write that needs to be fixed.




Jeff

[-- Attachment #2: t.61.i.gz --]
[-- Type: application/x-gzip, Size: 52831 bytes --]

Re: Failures building glibc with mainline GCC

[Martin Sebor via Libc-alpha]

On 7/30/21 9:30 AM, Joseph Myers 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>.

I submitted a patch for this warning to Glibc:
https://sourceware.org/pipermail/libc-alpha/2021-July/128829.html
which is what ultimately precipitated Florian's question.  If null
pointers to named address spaces are valid I'll adjust GCC to
avoid the warning for now (as has been discussed, for GCC 12 I'd
like to redo the logic to detect the problematic null pointer
arithmetic instead).

I haven't seen the rest of the warnings in my tests but
the uninit one could be due to the interaction of the recent
threader changes and a -Wuninitialized enhancement I committed
earlier this week that I didn't test with the new threader (but
did with Glibc with no new warnings).  I'll look into the warnings
if I can quickly reproduce them with a native x86_64-linux build
or get the translation units for other targets.

Martin

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

Re: Failures building glibc with mainline GCC

[Jakub Jelinek via Libc-alpha]

On Fri, Jul 30, 2021 at 10:53:28AM -0600, Martin Sebor via Gcc wrote:
> On 7/30/21 9:30 AM, Joseph Myers 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>.
> 
> I submitted a patch for this warning to Glibc:
> https://sourceware.org/pipermail/libc-alpha/2021-July/128829.html
> which is what ultimately precipitated Florian's question.  If null
> pointers to named address spaces are valid I'll adjust GCC to
> avoid the warning for now (as has been discussed, for GCC 12 I'd
> like to redo the logic to detect the problematic null pointer
> arithmetic instead).

They are valid for some address spaces.
See e.g. how gimple.c (check_loadstore) used by
infer_nonnull_range_by_dereference uses a target hook for that:
      /* Some address spaces may legitimately dereference zero.  */
      addr_space_t as = TYPE_ADDR_SPACE (TREE_TYPE (op));
      if (targetm.addr_space.zero_address_valid (as))
        return false;

	Jakub

Re: Failures building glibc with mainline GCC

[Martin Sebor via Libc-alpha]

On 7/30/21 10:45 AM, Jeff Law via Gcc wrote:
> 
> 
> On 7/30/2021 10:19 AM, Aldy Hernandez via Libc-alpha wrote:
>> 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.
> [ ... ]
> Ugh.  First attempt got blocked as message was slightly too big.
> 
> I think this is pretty generic as I've seen it on multiple ports and 
> Joseph mentioned them as well.
> 
> With an s390-linux-gnu (not s390x!) cross compiler you should be able to 
> trigger:
> 
> bash-5.1# s390-linux-gnu-gcc -std=gnu99 -O2 -Wall -mlong-double-128 *.i
> 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: warning: writing 1 byte into a region of size 0 
> [-Wstringop-overflow=]
> In file included from t.61.c:437:
> ../iconv/loop.c: In function 'gconv':
> ../iconv/loop.c:382:17: note: at offset 2 into destination object 
> 'bytebuf' of size 2
> 
> 
> I don't know if it's a real failure or a false positive.  I haven't even 
> bisected, but I suspect the new threader is the triggering change. 
> Ideally the threader threaded a path we hadn't previously and by some 
> chain of events exposed a out of bounds write that needs to be fixed.

The warning is valid for the IL.  Bytebuf is unsigned char[2] and
in bb 25 the warning sees:

   <bb 25> [local count: 2288797]:
   _613 = *inptr_96;
   bytebuf[2] = _613;               <<< -Wstringop-overflow
   goto <bb 32>; [100.00%]

GCC can't tell if the code is reachable and neither can I.  As
far as I can see it's the result of unrolling one if the loops
in the function, likely this one:

   do
     bytebuf[inlen++] = *inptr++;
   while (inlen < 2 && inptr < inend);

Adding:

   if (inlen >= 2) __builtin_unreachable ();

just above it avoids the warning.

Martin

Re: Failures building glibc with mainline GCC

[Joseph Myers]

On Fri, 30 Jul 2021, Aldy Hernandez via Gcc wrote:

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

Reverting that commit fixes all the glibc build failures except for 
x86_64-linux-gnu, i686-gnu and powerpc64le-linux-gnu.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Failures building glibc with mainline GCC

[Martin Sebor via Libc-alpha]

On 7/30/21 2:52 PM, Joseph Myers wrote:
> On Fri, 30 Jul 2021, Aldy Hernandez via Gcc wrote:
> 
>> 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?
> 
> Reverting that commit fixes all the glibc build failures except for
> x86_64-linux-gnu, i686-gnu and powerpc64le-linux-gnu.
> 

I just built Glibc for x86_64-linux-gnu with the top of trunk and
got no unexpected warnings.  Can you please share the translation
units for the files with the warnings?  (Or just open GCC bugs for
them if you believe they're false positives.)

Thanks
Martin

Re: Failures building glibc with mainline GCC

[Joseph Myers]

[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]

On Mon, 2 Aug 2021, Martin Sebor via Gcc wrote:

> On 7/30/21 2:52 PM, Joseph Myers wrote:
> > On Fri, 30 Jul 2021, Aldy Hernandez via Gcc wrote:
> > 
> > > 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?
> > 
> > Reverting that commit fixes all the glibc build failures except for
> > x86_64-linux-gnu, i686-gnu and powerpc64le-linux-gnu.
> > 
> 
> I just built Glibc for x86_64-linux-gnu with the top of trunk and
> got no unexpected warnings.  Can you please share the translation
> units for the files with the warnings?  (Or just open GCC bugs for
> them if you believe they're false positives.)

I still see the same error previously discussed for x86_64-linux-gnu.  
Compile the attached file with -O2 -Wall -Werror.

loadmsgcat.c: In function '_nl_load_domain':
loadmsgcat.c:770:22: error: array subscript 0 is outside array bounds of '__seg_fs struct pthread * __seg_fs[0]' [-Werror=array-bounds]

As discussed, this is a bug indicating that the code generating that 
warning fails to check targetm.addr_space.zero_address_valid to determine 
whether zero or small constant addresses are valid in the given address 
space.

-- 
Joseph S. Myers
joseph@codesourcery.com

[-- Attachment #2: Type: application/gzip, Size: 57342 bytes --]

Re: Failures building glibc with mainline GCC

[Martin Sebor via Libc-alpha]

On 8/3/21 9:54 AM, Joseph Myers wrote:
> On Mon, 2 Aug 2021, Martin Sebor via Gcc wrote:
> 
>> On 7/30/21 2:52 PM, Joseph Myers wrote:
>>> On Fri, 30 Jul 2021, Aldy Hernandez via Gcc wrote:
>>>
>>>> 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?
>>>
>>> Reverting that commit fixes all the glibc build failures except for
>>> x86_64-linux-gnu, i686-gnu and powerpc64le-linux-gnu.
>>>
>>
>> I just built Glibc for x86_64-linux-gnu with the top of trunk and
>> got no unexpected warnings.  Can you please share the translation
>> units for the files with the warnings?  (Or just open GCC bugs for
>> them if you believe they're false positives.)
> 
> I still see the same error previously discussed for x86_64-linux-gnu.
> Compile the attached file with -O2 -Wall -Werror.
> 
> loadmsgcat.c: In function '_nl_load_domain':
> loadmsgcat.c:770:22: error: array subscript 0 is outside array bounds of '__seg_fs struct pthread * __seg_fs[0]' [-Werror=array-bounds]
> 
> As discussed, this is a bug indicating that the code generating that
> warning fails to check targetm.addr_space.zero_address_valid to determine
> whether zero or small constant addresses are valid in the given address
> space.

Yes, we know about that one.  What I'm asking for is the translation
units with the other warnings you showed with the latest GCC (including
the threader patches) on the other targets (including i686 and power).
I don't have an easy way to create them using my setup.

Martin

Re: Failures building glibc with mainline GCC

[Joseph Myers]

[-- Attachment #1: Type: text/plain, Size: 1687 bytes --]

On Tue, 3 Aug 2021, Martin Sebor via Gcc wrote:

> Yes, we know about that one.  What I'm asking for is the translation
> units with the other warnings you showed with the latest GCC (including
> the threader patches) on the other targets (including i686 and power).
> I don't have an easy way to create them using my setup.

I've attached (all gzipped) hurdselect.i (i686-gnu, -O2 -Wall -Werror 
-Wno-parentheses):

hurdselect.c: In function '_hurd_select':
hurdselect.c:555:7: error: 'ss' may be used uninitialized in this function [-Werror=maybe-uninitialized]
hurdselect.c:70:25: note: 'ss' was declared here

and t.61.i (powerpc-linux-gnu, -O2 -Wall -Werror):

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=]
In file included from t.61.c:437:
../iconv/loop.c: In function 'gconv':
../iconv/loop.c:382:17: note: at offset 2 into destination object 'bytebuf' of size 2

and dl-tls.i (powerpc64-linux-gnu, -O2 -finline-limit=2000 -Wall -Werror; 
the -finline-limit=2000 option is necessary for the error and comes from 
sysdeps/powerpc/powerpc64/Makefile):

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]
../elf/dl-tls.c:544:40: error: array subscript -1 is outside array bounds of 'void[9223372036854775807]' [-Werror=array-bounds]

-- 
Joseph S. Myers
joseph@codesourcery.com

[-- Attachment #2: Type: application/gzip, Size: 60275 bytes --]

[-- Attachment #3: Type: application/gzip, Size: 51894 bytes --]

[-- Attachment #4: Type: application/gzip, Size: 56739 bytes --]

Re: Failures building glibc with mainline GCC

[Samuel Thibault via Libc-alpha]

Joseph Myers, le mar. 03 août 2021 17:21:59 +0000, a ecrit:
> On Tue, 3 Aug 2021, Martin Sebor via Gcc wrote:
> 
> > Yes, we know about that one.  What I'm asking for is the translation
> > units with the other warnings you showed with the latest GCC (including
> > the threader patches) on the other targets (including i686 and power).
> > I don't have an easy way to create them using my setup.
> 
> I've attached (all gzipped) hurdselect.i (i686-gnu, -O2 -Wall -Werror 
> -Wno-parentheses):
> 
> hurdselect.c: In function '_hurd_select':
> hurdselect.c:555:7: error: 'ss' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> hurdselect.c:70:25: note: 'ss' was declared here

That's a spurious warning, but I have pushed a trivial workaround.

Samuel

Re: Failures building glibc with mainline GCC

[Segher Boessenkool]

On Tue, Aug 03, 2021 at 10:20:49AM -0600, Martin Sebor via Gcc wrote:
> On 8/3/21 9:54 AM, Joseph Myers wrote:
> >As discussed, this is a bug indicating that the code generating that
> >warning fails to check targetm.addr_space.zero_address_valid to determine
> >whether zero or small constant addresses are valid in the given address
> >space.
> 
> Yes, we know about that one.  What I'm asking for is the translation
> units with the other warnings you showed with the latest GCC (including
> the threader patches) on the other targets (including i686 and power).
> I don't have an easy way to create them using my setup.

But you do have a cfarm account :-)


Segher

Re: Failures building glibc with mainline GCC

[Joseph Myers]

On Tue, 3 Aug 2021, Segher Boessenkool wrote:

> On Tue, Aug 03, 2021 at 10:20:49AM -0600, Martin Sebor via Gcc wrote:
> > On 8/3/21 9:54 AM, Joseph Myers wrote:
> > >As discussed, this is a bug indicating that the code generating that
> > >warning fails to check targetm.addr_space.zero_address_valid to determine
> > >whether zero or small constant addresses are valid in the given address
> > >space.
> > 
> > Yes, we know about that one.  What I'm asking for is the translation
> > units with the other warnings you showed with the latest GCC (including
> > the threader patches) on the other targets (including i686 and power).
> > I don't have an easy way to create them using my setup.
> 
> But you do have a cfarm account :-)

And build-many-glibcs.py is designed to be self-contained (depending only 
on the Python 3 standard library and basic native compilation tools), so 
having got a copy from a glibc checkout, you can do (given /some/where as 
the directory in which you want build-many-glibcs.py to do its checkouts 
and builds):

build-many-glibcs.py /some/where checkout gcc-vcs-mainline
/some/where/src/glibc/scripts/build-many-glibcs.py /some/where host-libraries
/some/where/src/glibc/scripts/build-many-glibcs.py --keep=failed /some/where compilers i686-gnu powerpc-linux-gnu powerpc64-linux-gnu

which will check out all the sources needed to build glibc, using mainline 
GCC, build the GMP/MPFR/MPC host libraries needed by GCC, then build cross 
toolchains for the three listed targets, keeping the build directories 
around for build stages that fail (in this case, the glibc build for those 
targets).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Failures building glibc with mainline GCC

[Segher Boessenkool]

Off-topic...

On Tue, Aug 03, 2021 at 09:00:20PM +0000, Joseph Myers wrote:
> On Tue, 3 Aug 2021, Segher Boessenkool wrote:
> > But you do have a cfarm account :-)
> 
> And build-many-glibcs.py is designed to be self-contained

[ snip ]

Yes, it's great :-)

> which will check out all the sources needed to build glibc, using mainline 
> GCC, build the GMP/MPFR/MPC host libraries needed by GCC,

It usually is preferred to use the existing host libraries, or to build
these libraries as part of the GCC build (as done with
contrib/download_prerequisites for example).



Segher

Re: Failures building glibc with mainline GCC

[Martin Sebor via Libc-alpha]

On 8/3/21 11:21 AM, Joseph Myers wrote:
> On Tue, 3 Aug 2021, Martin Sebor via Gcc wrote:
> 
>> Yes, we know about that one.  What I'm asking for is the translation
>> units with the other warnings you showed with the latest GCC (including
>> the threader patches) on the other targets (including i686 and power).
>> I don't have an easy way to create them using my setup.
> 
> I've attached (all gzipped) hurdselect.i (i686-gnu, -O2 -Wall -Werror
> -Wno-parentheses):

Thanks.

> 
> hurdselect.c: In function '_hurd_select':
> hurdselect.c:555:7: error: 'ss' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> hurdselect.c:70:25: note: 'ss' was declared here

This is a false positive caused by the overly restrictive analysis
limits hardwired into GCC (like PR 85872).  I have a patch that
relaxes the limits and that avoids the warning in this case but
it's not yet ready.

> 
> and t.61.i (powerpc-linux-gnu, -O2 -Wall -Werror):
> 
> 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=]
> In file included from t.61.c:437:
> ../iconv/loop.c: In function 'gconv':
> ../iconv/loop.c:382:17: note: at offset 2 into destination object 'bytebuf' of size 2

This is the same warning as Jeff noted on s390-linux-gnu and that
I explained in my reply:
   https://gcc.gnu.org/pipermail/gcc/2021-July/236943.html
There's nothing the warning alone can do to avoid triggering in these
cases (unrolling too many iterations of a loop).  The unroller does
have code to avoid doing this (infer_loop_bounds_from_undefined) but
it's not good enough.  Using -fno-aggressive-loop-optimizations
prevents the warning.

> and dl-tls.i (powerpc64-linux-gnu, -O2 -finline-limit=2000 -Wall -Werror;
> the -finline-limit=2000 option is necessary for the error and comes from
> sysdeps/powerpc/powerpc64/Makefile):
> 
> 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]
> ../elf/dl-tls.c:544:40: error: array subscript -1 is outside array bounds of 'void[9223372036854775807]' [-Werror=array-bounds]
> 

These warnings are reproducible even with a native x86_64 compiler
and the same option.  It's most likely due to the same root cause
as PR 101600 (the one in comment #0, not comment #2).  I don't have
a fix for it yet but it shouldn't be too hard.

Martin

Re: Failures building glibc with mainline GCC

[Martin Sebor via Libc-alpha]

On 8/3/21 3:00 PM, Joseph Myers wrote:
> On Tue, 3 Aug 2021, Segher Boessenkool wrote:
> 
>> On Tue, Aug 03, 2021 at 10:20:49AM -0600, Martin Sebor via Gcc wrote:
>>> On 8/3/21 9:54 AM, Joseph Myers wrote:
>>>> As discussed, this is a bug indicating that the code generating that
>>>> warning fails to check targetm.addr_space.zero_address_valid to determine
>>>> whether zero or small constant addresses are valid in the given address
>>>> space.
>>>
>>> Yes, we know about that one.  What I'm asking for is the translation
>>> units with the other warnings you showed with the latest GCC (including
>>> the threader patches) on the other targets (including i686 and power).
>>> I don't have an easy way to create them using my setup.
>>
>> But you do have a cfarm account :-)
> 
> And build-many-glibcs.py is designed to be self-contained (depending only
> on the Python 3 standard library and basic native compilation tools), so
> having got a copy from a glibc checkout, you can do (given /some/where as
> the directory in which you want build-many-glibcs.py to do its checkouts
> and builds):
> 
> build-many-glibcs.py /some/where checkout gcc-vcs-mainline
> /some/where/src/glibc/scripts/build-many-glibcs.py /some/where host-libraries
> /some/where/src/glibc/scripts/build-many-glibcs.py --keep=failed /some/where compilers i686-gnu powerpc-linux-gnu powerpc64-linux-gnu
> 
> which will check out all the sources needed to build glibc, using mainline
> GCC, build the GMP/MPFR/MPC host libraries needed by GCC, then build cross
> toolchains for the three listed targets, keeping the build directories
> around for build stages that fail (in this case, the glibc build for those
> targets).
> 

Thanks for the instructions.  I assumed that the purpose of these
automated builders and testers was to help us quickly find and
more easily root cause problems without each of us having to do
builds on all these targets ourselves.  If asking for translation
units to go with the problems your testers uncover is an imposition
I apologize.  In that event, I would suggest to submit bug reports
in Bugzilla instead with the usual details attached there.

Martin