From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-91403-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 121899 invoked by alias); 3 Apr 2018 22:48:36 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 121888 invoked by uid 89); 3 Apr 2018 22:48:35 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy=nature
X-HELO: relay1.mentorg.com
Date: Tue, 03 Apr 2018 22:48:00 -0000
From: Joseph Myers <joseph@codesourcery.com>
To: Zack Weinberg <zackw@panix.com>
CC: Florian Weimer <fweimer@redhat.com>, Thomas Schwinge
	<thomas@codesourcery.com>, GNU C Library <libc-alpha@sourceware.org>,
	<bug-hurd@gnu.org>, David Michael <fedora.dm0@gmail.com>
Subject: Re: Upstreaming the glibc Hurd port
In-Reply-To: <CAKCAbMjiPQce-hk-nAdHNTEyBwtLESkqntmjv23dzRbhmLQ__g@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1804032240180.10382@digraph.polyomino.org.uk>
References: <87a7xaupjx.fsf@euler.schwinge.homeip.net> <alpine.DEB.2.20.1801191721480.329@digraph.polyomino.org.uk> <20180124011051.5s2vugyq3ybnurwc@var.youpi.perso.aquilenet.fr> <20180124012726.tibylwp4re5dtgc3@var.youpi.perso.aquilenet.fr>
 <20180125014143.2hxhzon5lzxtqq6j@var.youpi.perso.aquilenet.fr> <alpine.DEB.2.20.1801251544550.22734@digraph.polyomino.org.uk> <20180319015122.j5tzslkdcnvampoh@var.youpi.perso.aquilenet.fr> <20180402001003.3u5n2p5pdmv4hos5@var.youpi.perso.aquilenet.fr>
 <alpine.DEB.2.20.1804031544350.27763@digraph.polyomino.org.uk> <alpine.DEB.2.20.1804032146390.10382@digraph.polyomino.org.uk> <20180403215844.e43apfrdw2tzjdon@var.youpi.perso.aquilenet.fr>
 <CAKCAbMjiPQce-hk-nAdHNTEyBwtLESkqntmjv23dzRbhmLQ__g@mail.gmail.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To
 svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1)
X-SW-Source: 2018-04/txt/msg00098.txt.bz2

On Tue, 3 Apr 2018, Zack Weinberg wrote:

> On Tue, Apr 3, 2018 at 5:58 PM, Samuel Thibault <samuel.thibault@gnu.org> wrote:
> > Joseph Myers, on mar. 03 avril 2018 21:48:32 +0000, wrote:
> >> The build for i686-gnu also fails using GCC 6 branch with
> >> build-many-glibcs.py:
> >>
> >> hurdsig.c: In function 'interrupted_reply_port_location.isra.1':
> >> hurdsig.c:250:39: error: 'portloc' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> >>    *(volatile mach_port_t *) portloc = *portloc;
> >>                                        ^~~~~~~~
> >>
> >> I haven't investigated whether this warning is valid, or whether it's
> >> bogus
> >
> > Well, it's completely bogus: portloc is initialized just above. I don't
> > understand why it wouldn't see that.
> 
> I think it thinks the *value pointed-to by portloc* is uninitialized.

This is just after a call to _hurdsig_catch_memory_fault, which is a macro 
involving a call to setjmp.  I think the returns-twice nature of setjmp is 
confusing the compiler into thinking portloc itself is uninitialized (I 
don't know why this particular warning) - in fact, the second return of 
setjmp will never reach the code getting the warning (as setjmp will 
return nonzero, so _hurdsig_catch_memory_fault will).

-- 
Joseph S. Myers
joseph@codesourcery.com