Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp2982351ybk; Mon, 18 May 2020 12:46:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzRJhBrBGhO0GK9WBvZCHFoScapV/J2Jm3LRF8zlUb/mlHEd3lDAp3Cbb9j1kvRaWGBSPpp X-Received: by 2002:a17:906:4e13:: with SMTP id z19mr15311239eju.339.1589831159923; Mon, 18 May 2020 12:45:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589831159; cv=none; d=google.com; s=arc-20160816; b=VDi7xiB5O/8IfPE+UI95Y0nk4Xd9y96s7wiv1oGC4JJwDjyFVfavbIjFKv0S7Z36n5 o+mMIs48/fJyDAsdONjihgG1Xjiv4z6pPaoN8SETJf3iO6w/2k+WejK3g8ndo1qnS3H4 V8+v3ehp8tUTUgbFvIy6X+6y4W08/xVICNxUgbnsPQ0DD194MHkWFAnQOag6zrsbL7Yy KvrBdmgjrPsAq/XE07bwbmm0Xbj1b5VGaEaDXafxZ29j/NKY5n8OptZUUY4J+LFoBW5R yjB4EwY5cxOaNMtWm6pktqvVflC8rHkEOrcjTMaBe6wM3IY+GhTUqujuAlW0X5Owt9Eg aBiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=hH1WblAXaXFa8z0dtnEpRSSbyrOUtSz8p6DJevhD59g=; b=C9ba6iEI/9ACEaM+zWt2Q0RTh8Fo/7VOd2qn/qjLnkgKxVtTW+2O97tF2ItEhTltu/ G9Qefs2auS/+uAIluNSQOekiVBa8zQDXcyIRIpF2kFETLWN3T4O698bkQRKIWxV6YhYB 5Qx3hAdvt2ITscaokEcINUEI+0H7iAHxg9v5Z3ZMYKdvBV6m+hweNkVlLGgWB/MEA6XZ dTXY1g5/jptOjLKMqw7MnThwujziYCyX0pnk2szS2GWvXW7mu0rQ7SdrnNuKn9hJIIr6 tkBLYHp5QsYrdZAIBphdiRM9ty0E5Udzik1HVuBdonCt4mvyTak/IUN/4O58Xfb2US4T 5X0A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=A5xbJOtO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c5si2329066edf.371.2020.05.18.12.45.36; Mon, 18 May 2020 12:45:59 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=A5xbJOtO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731506AbgERSJe (ORCPT + 99 others); Mon, 18 May 2020 14:09:34 -0400 Received: from mail.kernel.org ([198.145.29.99]:54546 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733161AbgERSG2 (ORCPT ); Mon, 18 May 2020 14:06:28 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D6F6F207D3; Mon, 18 May 2020 18:06:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1589825187; bh=M9XhHl33YZ6sKbCBzyoU1iRxB+7oyUhrZghe6cO4qUs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=A5xbJOtOoApPqcjB+7q/TfgqxISVYhh1rj6ANJRU1ObhRNtoH9mktD/nPkcdBzmH6 7Tyf8HvR6ZotbHPrB1CbZEI5tUHChdkeNsB5EB3HYFS6/ZmXlug5mOJM/miXdeJ9em 3f7S/NFs1WTQQ3YVHQPMXJTUF4Ula3IoSGF/yYd8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Linus Torvalds Subject: [PATCH 5.6 126/194] Stop the ad-hoc games with -Wno-maybe-initialized Date: Mon, 18 May 2020 19:36:56 +0200 Message-Id: <20200518173542.024910927@linuxfoundation.org> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200518173531.455604187@linuxfoundation.org> References: <20200518173531.455604187@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Linus Torvalds commit 78a5255ffb6a1af189a83e493d916ba1c54d8c75 upstream. We have some rather random rules about when we accept the "maybe-initialized" warnings, and when we don't. For example, we consider it unreliable for gcc versions < 4.9, but also if -O3 is enabled, or if optimizing for size. And then various kernel config options disabled it, because they know that they trigger that warning by confusing gcc sufficiently (ie PROFILE_ALL_BRANCHES). And now gcc-10 seems to be introducing a lot of those warnings too, so it falls under the same heading as 4.9 did. At the same time, we have a very straightforward way to _enable_ that warning when wanted: use "W=2" to enable more warnings. So stop playing these ad-hoc games, and just disable that warning by default, with the known and straight-forward "if you want to work on the extra compiler warnings, use W=123". Would it be great to have code that is always so obvious that it never confuses the compiler whether a variable is used initialized or not? Yes, it would. In a perfect world, the compilers would be smarter, and our source code would be simpler. That's currently not the world we live in, though. Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- Makefile | 7 +++---- init/Kconfig | 18 ------------------ kernel/trace/Kconfig | 1 - 3 files changed, 3 insertions(+), 23 deletions(-) --- a/Makefile +++ b/Makefile @@ -708,10 +708,6 @@ else ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE KBUILD_CFLAGS += -Os endif -ifdef CONFIG_CC_DISABLE_WARN_MAYBE_UNINITIALIZED -KBUILD_CFLAGS += -Wno-maybe-uninitialized -endif - # Tell gcc to never replace conditional load with a non-conditional one KBUILD_CFLAGS += $(call cc-option,--param=allow-store-data-races=0) @@ -861,6 +857,9 @@ KBUILD_CFLAGS += -Wno-pointer-sign # disable stringop warnings in gcc 8+ KBUILD_CFLAGS += $(call cc-disable-warning, stringop-truncation) +# Enabled with W=2, disabled by default as noisy +KBUILD_CFLAGS += $(call cc-disable-warning, maybe-uninitialized) + # disable invalid "can't wrap" optimizations for signed / pointers KBUILD_CFLAGS += $(call cc-option,-fno-strict-overflow) --- a/init/Kconfig +++ b/init/Kconfig @@ -36,22 +36,6 @@ config TOOLS_SUPPORT_RELR config CC_HAS_ASM_INLINE def_bool $(success,echo 'void foo(void) { asm inline (""); }' | $(CC) -x c - -c -o /dev/null) -config CC_HAS_WARN_MAYBE_UNINITIALIZED - def_bool $(cc-option,-Wmaybe-uninitialized) - help - GCC >= 4.7 supports this option. - -config CC_DISABLE_WARN_MAYBE_UNINITIALIZED - bool - depends on CC_HAS_WARN_MAYBE_UNINITIALIZED - default CC_IS_GCC && GCC_VERSION < 40900 # unreliable for GCC < 4.9 - help - GCC's -Wmaybe-uninitialized is not reliable by definition. - Lots of false positive warnings are produced in some cases. - - If this option is enabled, -Wno-maybe-uninitialzed is passed - to the compiler to suppress maybe-uninitialized warnings. - config CONSTRUCTORS bool depends on !UML @@ -1249,14 +1233,12 @@ config CC_OPTIMIZE_FOR_PERFORMANCE config CC_OPTIMIZE_FOR_PERFORMANCE_O3 bool "Optimize more for performance (-O3)" depends on ARC - imply CC_DISABLE_WARN_MAYBE_UNINITIALIZED # avoid false positives help Choosing this option will pass "-O3" to your compiler to optimize the kernel yet more for performance. config CC_OPTIMIZE_FOR_SIZE bool "Optimize for size (-Os)" - imply CC_DISABLE_WARN_MAYBE_UNINITIALIZED # avoid false positives help Choosing this option will pass "-Os" to your compiler resulting in a smaller kernel. --- a/kernel/trace/Kconfig +++ b/kernel/trace/Kconfig @@ -466,7 +466,6 @@ config PROFILE_ANNOTATED_BRANCHES config PROFILE_ALL_BRANCHES bool "Profile all if conditionals" if !FORTIFY_SOURCE select TRACE_BRANCH_PROFILING - imply CC_DISABLE_WARN_MAYBE_UNINITIALIZED # avoid false positives help This tracer profiles all branch conditions. Every if () taken in the kernel is recorded whether it hit or miss.