unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Martin Sebor via Libc-alpha <libc-alpha@sourceware.org>
To: Joseph Myers <joseph@codesourcery.com>,
	libc-alpha@sourceware.org, gcc@gcc.gnu.org
Subject: Re: Failures building glibc with mainline GCC
Date: Fri, 30 Jul 2021 10:53:28 -0600	[thread overview]
Message-ID: <1bcf4c26-1619-06fa-fd8d-4e944ac6f07a@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2107301518250.581212@digraph.polyomino.org.uk>

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


  parent reply	other threads:[~2021-07-30 16:53 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-30 15:30 Failures building glibc with mainline GCC Joseph Myers
2021-07-30 16:19 ` Aldy Hernandez via Libc-alpha
2021-07-30 16:22   ` Jeff Law via Libc-alpha
2021-07-30 16:45   ` Jeff Law via Libc-alpha
2021-07-30 17:28     ` Martin Sebor via Libc-alpha
2021-07-30 20:52   ` Joseph Myers
2021-08-02 20:20     ` Martin Sebor via Libc-alpha
2021-08-03 15:54       ` Joseph Myers
2021-08-03 16:20         ` Martin Sebor via Libc-alpha
2021-08-03 17:21           ` Joseph Myers
2021-08-03 17:39             ` Samuel Thibault via Libc-alpha
2021-08-03 22:33             ` Martin Sebor via Libc-alpha
2021-08-03 20:50           ` Segher Boessenkool
2021-08-03 21:00             ` Joseph Myers
2021-08-03 22:02               ` Segher Boessenkool
2021-08-03 22:59               ` Martin Sebor via Libc-alpha
2021-07-30 16:38 ` Joseph Myers
2021-07-30 16:43   ` Jakub Jelinek via Libc-alpha
2021-07-30 16:53 ` Martin Sebor via Libc-alpha [this message]
2021-07-30 17:02   ` Jakub Jelinek via Libc-alpha

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/libc/involved.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1bcf4c26-1619-06fa-fd8d-4e944ac6f07a@gmail.com \
    --to=libc-alpha@sourceware.org \
    --cc=gcc@gcc.gnu.org \
    --cc=joseph@codesourcery.com \
    --cc=msebor@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).