From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756600AbcBDMk5 (ORCPT ); Thu, 4 Feb 2016 07:40:57 -0500 Received: from mout.kundenserver.de ([217.72.192.73]:63349 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932966AbcBDMkz (ORCPT ); Thu, 4 Feb 2016 07:40:55 -0500 From: Arnd Bergmann To: Andrzej Hajda Cc: Andrew Morton , Bartlomiej Zolnierkiewicz , Marek Szyprowski , open list , Bob Peterson Subject: Re: [PATCH v3] err.h: allow IS_ERR_VALUE to handle properly more types Date: Thu, 04 Feb 2016 13:40:38 +0100 Message-ID: <13351313.c4ZqBbQEld@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <1454505328-26019-1-git-send-email-a.hajda@samsung.com> References: <20160202163350.f7d42f4b97f48756f3900e9a@linux-foundation.org> <1454505328-26019-1-git-send-email-a.hajda@samsung.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:CeeIllsisWutyIhPNwVYcLBzNgw7ycOJexb5tsssbnEA+EB+RlS ZHEQDa5ot2T/cpZVKqr8lwOHhnvY4mIM3QwS08ZvdW8tplelDJjQvHNxZh4OECDVWdBblCV /SXfDZd71NCuxfK7sAlIVlAjkEuZ+LxFO7joQ1j4S3nNqxef/74NucqmNEV0rEfRoP3y613 nRoOt+FjR1+nk0pRwEQxw== X-UI-Out-Filterresults: notjunk:1;V01:K0:FYLe62PCIPc=:aBtsE/4DURaDjZWhhM3Jfv XN5Jh6ZjAv5y9ztgk2ECF8sQWn4MJTOOYJKH3XMEMoEHwSd50lXUK+GhqaUuFNGxavpaEOK3G WFOIdwlgt0hOjLnJbVXydXiRTJfhh9XCYkfC4d1uzKj7ttA47fPR6Jtj/B2+YJgWjHDKYAeKb nYLzK0MKaTm2pYssXpYntWIPnBkuabQ+23mXK3S27OHvBNgk+tKCRTOYYd34ofBJJLXtA9TrN MPW3Ace/AKbt82mb2VwOZjX6jynjX7eqsUpiUOx6Q4qPPopa1IAZuiKPg7l7t5mXZyuodGrqK 3PFtiRxUMzkXqui5q+Lju3gUgkgrU+J23bCLo4mSBjLSRorqsE7rehyk9lLgbuQENIVtC7jHE Md9GQKWee4eyAGJOAjHYwc39tLDeUogucmerVRo4RJzyjLj/NGzz4ivJCXC3nwqr7uEeTaV3q sPjqExahh6b820OsmcZLTdclbLw4/O0ImyWXnNJK1FB7pg+RxiWyEQARCCvVN7mVaZ7ovVZLC 7Ecxw2OhDsrOdajuzd+zWQqKEBpbIiNMbp1EXTrK3QhHAB4BSGAK+wbeOSSjj3NToZOhQ5ia/ v7prPgn9pJTjTpTevLF2I8QLKn/ICxRyaOgiSSSpQKxIhSpREI+n1S4FjIMcCwS79NA6QrfMC R3lkkwPL9YYMq6zjQPDujz3dyswpfobHrZwGO7pfdzHc5gIFolVndofcmALZHXRZn9moLlajP 5Ui1dqupFlC95wX5 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday 03 February 2016 14:15:28 Andrzej Hajda wrote: > diff --git a/include/linux/err.h b/include/linux/err.h > index 56762ab..b7d4a9f 100644 > --- a/include/linux/err.h > +++ b/include/linux/err.h > @@ -18,7 +18,9 @@ > > #ifndef __ASSEMBLY__ > > -#define IS_ERR_VALUE(x) unlikely((x) >= (unsigned long)-MAX_ERRNO) > +#define IS_ERR_VALUE(x) ((typeof(x))(-1) <= 0 \ > + ? unlikely((x) <= -1) \ > + : unlikely((x) >= (typeof(x))-MAX_ERRNO)) > > static inline void * __must_check ERR_PTR(long error) > { > This has caused a warning to reappear that I had fixed before: fs/gfs2/dir.c: In function 'get_first_leaf': fs/gfs2/dir.c:802:9: warning: 'leaf_no' may be used uninitialized in this function [-Wmaybe-uninitialized] error = get_leaf(dip, leaf_no, bh_out); ^ fs/gfs2/dir.c: In function 'dir_split_leaf': fs/gfs2/dir.c:1021:8: warning: 'leaf_no' may be used uninitialized in this function [-Wmaybe-uninitialized] error = get_leaf(dip, leaf_no, &obh); See my original patch that was applied at http://www.gossamer-threads.com/lists/linux/kernel/2353964 Apparently the new version is complex enough to prevent gcc from doing some optimizations it should do. I have tried to come up with a new variant that does not bring the warning back and that should work in all cases: diff --git a/include/linux/err.h b/include/linux/err.h index b7d4a9ff6342..bd4936a2c352 100644 --- a/include/linux/err.h +++ b/include/linux/err.h @@ -18,9 +18,7 @@ #ifndef __ASSEMBLY__ -#define IS_ERR_VALUE(x) ((typeof(x))(-1) <= 0 \ - ? unlikely((x) <= -1) \ - : unlikely((x) >= (typeof(x))-MAX_ERRNO)) +#define IS_ERR_VALUE(x) (unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO)) static inline void * __must_check ERR_PTR(long error) { I'm not sure if the cast to 'unsigned long long' might cause less efficient code to be generated by gcc. I would hope that it is smart enough to not actually extend shorter variables to 64 bit before doing the comparison but I have not checked yet. Arnd