From patchwork Fri May 27 12:33:05 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Arnd Bergmann X-Patchwork-Id: 9138247 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 482086075C for ; Fri, 27 May 2016 12:33:21 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2EF6F27CF9 for ; Fri, 27 May 2016 12:33:21 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 2169E2818B; Fri, 27 May 2016 12:33:21 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1670C27CF9 for ; Fri, 27 May 2016 12:33:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751149AbcE0MdT (ORCPT ); Fri, 27 May 2016 08:33:19 -0400 Received: from mout.kundenserver.de ([212.227.17.10]:53783 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750985AbcE0MdS convert rfc822-to-8bit (ORCPT ); Fri, 27 May 2016 08:33:18 -0400 Received: from wuerfel.localnet ([78.42.132.4]) by mrelayeu.kundenserver.de (mreue101) with ESMTPSA (Nemesis) id 0MXHhV-1b3GF82Akv-00WDWz; Fri, 27 May 2016 14:32:55 +0200 From: Arnd Bergmann To: Linus Torvalds Cc: Michal Marek , mussitantesmortem@gmail.com, nicolas.ferre@atmel.com, Nicolas Pitre , robert.jarzmik@free.fr, yamada.masahiro@socionext.com, Linux Kbuild mailing list , Linux Kernel Mailing List , Bob Peterson Subject: Re: [GIT PULL] kbuild updates for v4.7-rc1 Date: Fri, 27 May 2016 14:33:05 +0200 Message-ID: <5345273.JScMX9oohG@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-22-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: References: <20160526203346.GA4734@pobox.suse.cz> MIME-Version: 1.0 X-Provags-ID: V03:K0:hUKschNCxoE2B8bx2BdhhUwGmB4CDzZghz2BTJd+Q/9txngCNm0 CIWuszsts4ODCFCj3pzjQP1Su0aTu3AUNJ6UiGQgN7TR2ykHVvDkyzXY6rRnFCsMWmYx+W4 Kq1uy2BZqEsFsYxIV/SvnBS8iHTN8u5Pn4t0VyEKWhDtRcWNLQfPGylSww8vP1HUVmiIdNb SASYFB+bE7IkGI0qBeBjg== X-UI-Out-Filterresults: notjunk:1; V01:K0:jDcwplah9qA=:NMSTgZGVIYRy4J9w13PJXi ywTiHd3+oUdKw8xpqmYduncAU0nqnyhYL/uuZZiOZMnOJt5o5VWGO9nLN9FVqlovXnhbuWyD8 VILZ11O111ZJUCWOQrmqtB8J0GIASbmKgoW17gEmzDgD0N2CILa278RXkhx0+t+Hs5bZwcing yAHRnE8XLqIhKvFN3OYtj4LsNRfKKc2ESSqyf/b++pZF3AUOUxxf6LpCsvZRx4ihcwvMlD/ks Z/OwJaLH9AauvPiEfLi2nJW/shI/sTMpN7azHsg9f4V8qXD9Xxed7WVLbzFWkKkt1CcuGUFs2 7W1cMzCROzZ5hb8Zj7JDXW9oFlNfIfefXhgIuSyb+UrLa7a51OvgTqX+GkT2NOst8BK+ofEmN 6q74bW/eaeZ13TLKcgwzVS+jLrfHDP1miDzh5TRA8M28TmNy5j7WiKKQH5fTEVDg4IvXdEU5G cWPOsZ3NnnMSRYQsN6+23Du8KflRA/0/fMqZxG3b7crQnpypeVQXj8/I9sfL2lIp211joxrRC ik9HHoEKoM37Ur7elJtkGTO62fhXVFJzJako1XPiC2EsJFbOnHnnjfiGKES6OSLmAz0xsgSE/ ZJeagCyl8ty2qHfNvrWKCu001AkNb0G/SsVrR95VUeRGor9qzkC6m1cQSB1gQQxNeuitYaONB YgS00Dc0RdQ4zHTShEa9axJJ6UXAXtIAw1npFX0MTCI/0Ozvr4dv3bMjdgXdO4kE1vFvJ+Nmd g40ca03v5BdGu07e Sender: linux-kbuild-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kbuild@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Thursday, May 26, 2016 10:26:50 PM CEST Linus Torvalds wrote: > On Thu, May 26, 2016 at 1:33 PM, Michal Marek wrote: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild.git kbuild > > This pull results in new warnings. > > I get new "may be uninitialized" warnings now for me allmodconfig > build, and while I didn't look at them all, the one I looked at was > just entirely crap: > > fs/gfs2/dir.c: In function ‘dir_split_leaf.isra.16’: > 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); > ^ > > yeah no, leaf_no is initialized a few lines up by > > error = get_leaf_nr(dip, index, &leaf_no); > > and the fact that gcc can't follow the trivial error handling is not > our fault. It looks *so* trivial that I wonder why. > > That said, I don't see exactly what in the pull request causes this. > > My reading of the diff seems to say that you are actually adding > *more* cases of -Wno-maybe-uninitialized, not less. I put the explanation for this into the individual patch commit logs. > So I suspect it's almost accidental in just how the Kconfig option > CC_OPTIMIZE_FOR_PERFORMANCE happened, which in turn probably just > changes the options for "make allmiodconfig", and it now picks a > non-size-optimized build that always showed those warnings and I just > didn't see them. Correct, the point of the CC_OPTIMIZE_FOR_PERFORMANCE change is that we now see the -Wmaybe-uninitialized warnings by default now. I also submitted patches for all warnings I saw a while ago, but some only happen with certain compiler versions that I don't regularly test on, or are architecture specific. The specific gfs2 warning is one that I fixed before but it came back after some back-and-forth discussions, and I forgot to post it again but kept it in my tree of backlog warning fixes, my mistake. I keep running into new valid Wmaybe-uninitialized warnings on randconfig builds, e.g. https://lkml.org/lkml/2016/5/27/99 today, and having them enabled in allmodconfig should make it easier for patch authors to catch them first. I don't currently get any other -Wmaybe-uninialized warnings using gcc-6 on ARM, but I get two warnings on x86, in drivers/net/wireless/wl3501_cs.c and drivers/net/wireless/intel/iwlwifi/mvm/nvm.c I'll have a look at those. Arnd 8<---- [PATCH] gfs2: avoid maybe-uninitialized warning again gcc can not always figure out which code is only used in an error condition an assignment to indirect argument is only done after the use of IS_ERR() catches errors. In gfs2, this results in a warning about correct code: 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] 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] I managed to work around this earlier using the IS_ERR_VALUE(), but unfortunately that did not catch all configurations. This new patch reworks the function in question to us PTR_ERR_OR_ZERO() instead, which makes it more obvious to the compiler what happens, and should also result in better object code. Signed-off-by: Arnd Bergmann Fixes: 67893f12e537 ("gfs2: avoid uninitialized variable warning") --- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/fs/gfs2/dir.c b/fs/gfs2/dir.c index 4a01f30e9995..271d93905bac 100644 --- a/fs/gfs2/dir.c +++ b/fs/gfs2/dir.c @@ -783,12 +783,15 @@ static int get_leaf_nr(struct gfs2_inode *dip, u32 index, u64 *leaf_out) { __be64 *hash; + int error; hash = gfs2_dir_get_hash_table(dip); - if (IS_ERR(hash)) - return PTR_ERR(hash); - *leaf_out = be64_to_cpu(*(hash + index)); - return 0; + error = PTR_ERR_OR_ZERO(hash); + + if (!error) + *leaf_out = be64_to_cpu(*(hash + index)); + + return error; } static int get_first_leaf(struct gfs2_inode *dip, u32 index, @@ -798,7 +801,7 @@ static int get_first_leaf(struct gfs2_inode *dip, u32 index, int error; error = get_leaf_nr(dip, index, &leaf_no); - if (!IS_ERR_VALUE(error)) + if (!error) error = get_leaf(dip, leaf_no, bh_out); return error; @@ -1014,7 +1017,7 @@ static int dir_split_leaf(struct inode *inode, const struct qstr *name) index = name->hash >> (32 - dip->i_depth); error = get_leaf_nr(dip, index, &leaf_no); - if (IS_ERR_VALUE(error)) + if (error) return error; /* Get the old leaf block */