bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Upstreaming the glibc Hurd port


From: Joseph Myers
Subject: Re: Upstreaming the glibc Hurd port
Date: Tue, 3 Apr 2018 22:46:11 +0000
User-agent: Alpine 2.20 (DEB 67 2015-01-07)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]