From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 625DE1F463 for ; Tue, 24 Sep 2019 20:21:24 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=ddjhD7XwzkOwEGLA 78ze2ddM6SxGVT1DJk2xD/ef/Sx/eignvytse4b3hdcTViXMllUWuzWdFYjPjkc8 INMhYiHtweENWDVoH8W+0SLciOi4Zt25UcwMYbCYS3fJJRWOBjlY/lqilvTOweTf litxepE9ttOi1ieBsQjamOZ4uTc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=R6XpGzoGl6Dc/Z1PGN/3UV spjuE=; b=ieNqVJTx9AUHNCIfjenFKZXogSl0usnRQqLvntXI3QK3ho2sLfqdxM 1v5ocvNTveOEi0BrmzzORSmIvGRvpV9Blkyjrn/1Du9jGJaHDhkZk8kLGz9BF+kR tZ3ZS3Z0ozLK9LkajVlsru3rVYxTQdIt/d1NnFDrOBEPGIM0o5QxU= Received: (qmail 103702 invoked by alias); 24 Sep 2019 20:21:21 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 103693 invoked by uid 89); 24 Sep 2019 20:21:21 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mx1.redhat.com Subject: Re: [PATCH] inet/net-internal.h: Fix uninitalised clntudp_call() variable To: Alistair Francis , libc-alpha@sourceware.org Cc: law@redhat.com, joseph@codesourcery.com, zackw@panix.com, macro@wdc.com, alistair23@gmail.com References: <20190916221536.18500-1-alistair.francis@wdc.com> From: Carlos O'Donell Message-ID: <83b0d556-ef9d-adbf-85ac-d4ef8857f9b9@redhat.com> Date: Tue, 24 Sep 2019 16:21:15 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190916221536.18500-1-alistair.francis@wdc.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 9/16/19 6:15 PM, Alistair Francis wrote: > The total_deadline variable inside the clntudp_call() function inside > sunrpc/clnt_udp.c can cause uninitalised variable warnings when building > with GCC 8.3 or 9.2 on a platform with a 64-bit tv_nsec on a 32-bit > architecture. To fix the warning let's use the DIAG_* macros to hide the > warning. > > A GCC bug case has also been submitted: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91691 > This looks good to me. If you're seeing this using the released 8.3 or 9.2 then others will see it too. You also reference the compiler version that is the latest with the problem e.g. 9. I don't think we should fix this by zeroing out the entire field since this looks like an optimization or compiler related issue. OK for master. Reviewed-by: Carlos O'Donell > 2019-09-16 Alistair Francis > > * inet/net-internal.h: Fix uninitalised clntudp_call() variable > --- > inet/net-internal.h | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/inet/net-internal.h b/inet/net-internal.h > index 2f522eef555..c774de2b78a 100644 > --- a/inet/net-internal.h > +++ b/inet/net-internal.h > @@ -23,6 +23,7 @@ > #include > #include > #include > +#include > > int __inet6_scopeid_pton (const struct in6_addr *address, > const char *scope, uint32_t *result); > @@ -96,6 +97,16 @@ __deadline_is_infinite (struct deadline deadline) > return deadline.absolute.tv_nsec < 0; > } > > +/* GCC 8.3 and 9.2 both incorrectly report total_deadline > + * (from sunrpc/clnt_udp.c) as maybe-uninitialized when tv_sec is 8 bytes > + * (64-bits) wide on 32-bit systems. We have to set -Wmaybe-uninitialized > + * here as it won't fix the error in sunrpc/clnt_udp.c. > + * A GCC bug has been filed here: > + * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91691 > + */ > +DIAG_PUSH_NEEDS_COMMENT; > +DIAG_IGNORE_NEEDS_COMMENT (9, "-Wmaybe-uninitialized"); > + > /* Return true if the current time is at the deadline or past it. */ > static inline bool > __deadline_elapsed (struct deadline_current_time current, > @@ -120,6 +131,8 @@ __deadline_first (struct deadline left, struct deadline right) > return right; > } > > +DIAG_POP_NEEDS_COMMENT; > + > /* Add TV to the current time and return it. Returns a special > infinite absolute deadline on overflow. */ > struct deadline __deadline_from_timeval (struct deadline_current_time, > -- Cheers, Carlos.