From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-91446-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 37695 invoked by alias); 5 Apr 2018 11:07:34 -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 37684 invoked by uid 89); 5 Apr 2018 11:07:33 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=
X-HELO: mx1.redhat.com
Subject: Re: Upstreaming the glibc Hurd port
To: Joseph Myers <joseph@codesourcery.com>,
 Thomas Schwinge <thomas@codesourcery.com>,
 GNU C Library <libc-alpha@sourceware.org>, bug-hurd@gnu.org,
 David Michael <fedora.dm0@gmail.com>
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>
From: Florian Weimer <fweimer@redhat.com>
Message-ID: <caad5316-2a65-982f-0c91-86edb759f92e@redhat.com>
Date: Thu, 05 Apr 2018 11:07:00 -0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <20180403215844.e43apfrdw2tzjdon@var.youpi.perso.aquilenet.fr>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-SW-Source: 2018-04/txt/msg00141.txt.bz2

On 04/03/2018 11:58 PM, Samuel Thibault 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.

You will have to look at the GIMPLE or assembler to determine if the 
warning is bogus after GCC has processed the setjmp call.  It may very 
well be the case that after those transformations, there *is* an 
uninitialized use of portloc.

Suppressing the warning could be the wrong thing to do here.  You may 
have to declare portloc itself volatile.

Thanks a lot for all these Hurd changes, by the way.  I really 
appreciate your work.

Thanks,
Florian