This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Uninitialized error with GCC mainline
- From: Markus Trippelsdorf <markus at trippelsdorf dot de>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Fri, 3 Mar 2017 16:13:41 +0100
- Subject: Re: Uninitialized error with GCC mainline
- Authentication-results: sourceware.org; auth=none
- References: <alpine.DEB.2.20.1703030151030.18481@digraph.polyomino.org.uk>
On 2017.03.03 at 01:55 +0000, Joseph Myers wrote:
> As shown at
> <https://sourceware.org/ml/libc-testresults/2017-q1/msg00210.html>,
> building with GCC mainline fails with an uninitialized variable error on
> many (all?) architectures:
>
> In file included from fnmatch.c:250:0:
> fnmatch_loop.c: In function 'internal_fnwmatch':
> ../locale/weightwc.h:103:28: error: '*((void *)&str+4)' may be used
> uninitialized in this function [-Werror=maybe-uninitialized]
> if (cp[nhere - 1] > usrc[nhere -1])
> ~~~~^~~~~~~~~~
>
> Building with GCC r245852 fails; building with GCC r245811, as in the
> previous build results
> <https://sourceware.org/ml/libc-testresults/2017-q1/msg00204.html>, passes
> with current glibc. So this results from some GCC change, not a glibc
> change. I haven't bisected to an individual revision. We need to figure
> out if this is a compiler bug, or a glibc bug, or a case where in fact the
> uninitialized use cannot occur but the compiler reasonably cannot see it,
> in which case diagnostic pragmas should be used as elsewhere in this file.
There are many more similar warnings later on.
This started with gcc's rr245840. It would be could if someone could
analyze the issues and open gcc bugs if necessary.
--
Markus