Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp1260853rwb; Tue, 27 Sep 2022 10:26:11 -0700 (PDT) X-Google-Smtp-Source: AMsMyM72OKm9FWPLS7irbAnAb9SZItzSKw8Ejm6WpF1vjf1Q53i/XdB0U/xX4i7aWsVJOXEivyha X-Received: by 2002:aa7:cf89:0:b0:457:3dff:8a4 with SMTP id z9-20020aa7cf89000000b004573dff08a4mr12794273edx.175.1664299571558; Tue, 27 Sep 2022 10:26:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1664299571; cv=none; d=google.com; s=arc-20160816; b=pe+xmginRWvw+pJFwzn6EuiDe77QQQ3dPdhUpCfFd43RoXQJrJ18eCRAxiRs/2fCqL 2oLedy4uRV/ThHusEqWIlXHIdBsLpCOfVs/YLB3ICo0RHOwbUT0Cutv0Kexzmmepoe5l kc9p32BYPBVH9XMpfz3biNODgPf9bDQKvHjHzv0IuhgvtygbNH8yKv1hct4YKymEfq0N NbVMixRxprbdchw+YggBscTXPa818psyxrHxEyFGiuiFBgdOsR+wM9FzCrJ2hw/I/bpg jGyMfsuEuTMziXor/NfyPM0ZUqRRUTi4Wv3zA5LfZHBEcvGm1eQhCJZIuvUFf4box6+V NMZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=DUH03Yy0FlWtvFEnmMS0SWW/twMFl5WCHNhYURM80Wk=; b=uBwUCAgaWYoMkcNHQE5DavYEQIFGhZpEl2HLJfgnP4KFlUxSszXfhih7ljiHHdYSl6 rgucLwBn9aARMC7BtNWseCG54hEap2WsnIMpjzWeTzBtWKhOyLupdDz8fINFs1FCnEoU kMvRAUM6TDokac4lUEYU+rEkEnA77ZVSrEGMq7SsBgcqF/nZKONsgDOoiqHvGcL4vwS4 pdA3B7X8KYTeGfiZCtaT5M1g+h0esBEZ1i+xHXZ9Vea83v0dh9c1J34siXnx6uDZXZL4 ISDUr04Aih29h0oZ0gzJcwMdTGXgV5fWhqYpYIZnS9S1iKUCyjqTQcK7ZZ1HNRF7aD67 jqWQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=uuH2xvOc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hc32-20020a17090716a000b0078773b9fe48si1572477ejc.855.2022.09.27.10.25.45; Tue, 27 Sep 2022 10:26:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=uuH2xvOc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232119AbiI0RCg (ORCPT + 99 others); Tue, 27 Sep 2022 13:02:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54774 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232091AbiI0RCX (ORCPT ); Tue, 27 Sep 2022 13:02:23 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 67599EC56F; Tue, 27 Sep 2022 10:02:21 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id AA1B660691; Tue, 27 Sep 2022 17:02:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E01FBC433C1; Tue, 27 Sep 2022 17:02:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1664298140; bh=JCOanzPCr3oWRV3li2/XhhZZdBH07whiMGtrcocbS5o=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=uuH2xvOc9JWfUDgIUBwiaABl73mOIi6AvtG60UI6YKqHCQJfFb1wxD7GxK+zze9Jk mvFlDwCz5/g2/Vu4Fe2vbEncyC79edGp8rKRkYcnHx33yoPixlLjQIXYpq1seZ498q D7CiA1SWGGh+k8Rpoesm96GFOZlva74hSPq8pI1flI0ZV90Iuq9/CXANJjn/Bnuk7c OZKVgb7+rtF22rHRFugwziCsvQk2Kpn3sdcDNeySgsFOz8GpoaI1DlbHAN95MiPDqt jRXw+RzN3Jjnv+/SWxqwTgVf3SrByEH/7eDPI3BTl0BksdWKwHx7Kx5H5d02/n/vax fJkhLb0RvqyFw== Date: Tue, 27 Sep 2022 10:02:17 -0700 From: Nathan Chancellor To: Nick Desaulniers Cc: Zeng Heng , masahiroy@kernel.org, michal.lkml@markovi.net, akpm@linux-foundation.org, peterz@infradead.org, keescook@chromium.org, davidgow@google.com, jpoimboe@kernel.org, dan.j.williams@intel.com, ojeda@kernel.org, isabbasso@riseup.net, dmitrii.bundin.a@gmail.com, vbabka@suse.cz, linux@rasmusvillemoes.dk, linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, liwei391@huawei.com, weiyongjun1@huawei.com, clang-built-linux , linux-toolchains Subject: Re: [PATCH -next] Makefile: add implicit enum-conversion check for compile build Message-ID: References: <20220927153125.811911-1-zengheng4@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 27, 2022 at 09:45:17AM -0700, Nick Desaulniers wrote: > On Tue, Sep 27, 2022 at 8:15 AM Zeng Heng wrote: > > > > Provide implicit enum-conversion warning option > > in general build. When it set enabled, it can > > detect implicit enum type conversion and find > > potential conversion errors like below > > (use "allmodconfig"): > > > > drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/display_mode_vba_20.c:3904:46: > > error: implicit conversion from ‘enum ’ to ‘enum odm_combine_mode’ [-Werror=enum-conversion] > > 3904 | locals->ODMCombineEnablePerState[i][k] = true; > > | ^ > > > > The '-Wenum-conversion' could be regarded as > > effective check on compile runtime and > > call attention on potential mistakes. > > > > Anothor practical example could be referred to: > > https://lore.kernel.org/all/CADnq5_OE0yZvEYGu82QJHL9wvVcTFZrmeTgX7URgh7FVA=jqYg@mail.gmail.com > > > > "-Wenum-conversion" was firstly introduced from > > GNU gcc-10. > > What about clang? ;) > > > > > Although "-Wenum-conversion" could be enabled > > by "-Wextra" when compiling with 'W=1' option, > > there are many warnings generated by '-Wextra' > > that cause too much noise in a build. > > With clang, I believe that -Wenum-conversion is part of -Wall or > -Wextra; so enabling this explicitly is only necessary for GCC. I > wonder why it's not part of -Wall or -Wextra for GCC? Perhaps worth a > bug report/feature request? With clang, -Wenum-conversion is just default enabled, not even behind -Wall: $ cat test.c enum enum1 { A = 1 }; enum enum2 { B = 2 }; enum enum1 foo(enum enum2 bar) { return bar; } $ clang -fsyntax-only test.c test.c:11:9: warning: implicit conversion from enumeration type 'enum enum2' to different enumeration type 'enum enum1' [-Wenum-conversion] return bar; ~~~~~~ ^~~ 1 warning generated. On the other hand, GCC does have it under -Wextra: $ gcc -fsyntax-only test.c $ gcc -Wextra -fsyntax-only test.c test.c: In function ‘foo’: test.c:6:16: warning: implicit conversion from ‘enum enum2’ to ‘enum enum1’ [-Wenum-conversion] 6 | return bar; | ^~~ But the kernel does not build with -Wextra aside from W=[123], hence this warning has to be explicitly requested for GCC. > > > > Seeing the details from the following link: > > https://gcc.gnu.org/onlinedocs/gcc-11.3.0/gcc/Warning-Options.html > > > > Because there are still some concerned warnings > > exist, the patch marks the option disabled in default > > for avoiding compile failed like using "allmodconfig". But there is no dependency to avoid this getting enabled by allmodconfig (such as 'depends on !COMPILE_TEST') so I don't see the point in the current form; 'default n' does nothing to prevent it. Regardless, I agree with Nick's sentiment below. > > Signed-off-by: Zeng Heng > > --- > > Makefile | 5 +++++ > > lib/Kconfig.debug | 7 +++++++ > > 2 files changed, 12 insertions(+) > > > > diff --git a/Makefile b/Makefile > > index ebd48fc956a3..1790a3624358 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -880,6 +880,11 @@ endif > > KBUILD_CFLAGS += $(call cc-disable-warning, unused-but-set-variable) > > KBUILD_CFLAGS += $(call cc-disable-warning, unused-const-variable) > > > > +# check implicit enum conversion > > +ifdef CONFIG_ENUM_CONVERSION > > +KBUILD_CFLAGS += -Wenum-conversion > > +endif > > Having a kconfig for this is overkill. cc-option with a comment about > the compiler default versions is the way to go. Agreed. If there is some reason -Wenum-conversion cannot be enabled for GCC right now (such as existing warnings, which the commit message appears to alude to), they should be cleaned up first then -Wenum-conversion should just be unconditionally enabled for all compilers that support it via cc-option, not half enabled via Kconfig so that maybe people will clean up the warnings. That is not how enabling warnings works: https://lore.kernel.org/CAHk-=wg-mH-_GYpkhz_psjBWG6ZcjKnPo83fg7YMj_by+-LRTQ@mail.gmail.com/ > > + > > # These result in bogus false positives > > KBUILD_CFLAGS += $(call cc-disable-warning, dangling-pointer) > > > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > > index 4f2b81229a2f..a64e06a747d8 100644 > > --- a/lib/Kconfig.debug > > +++ b/lib/Kconfig.debug > > @@ -417,6 +417,13 @@ config FRAME_WARN > > Setting this too low will cause a lot of warnings. > > Setting it to 0 disables the warning. > > > > +config ENUM_CONVERSION > > + bool "Warn for implicit enum conversion" > > + depends on GCC_VERSION >= 100300 > > + default n > > + help > > + Tell gcc to warn at build time for implicit enum conversion. > > + > > config STRIP_ASM_SYMS > > bool "Strip assembler-generated symbols during link" > > default n > > -- > > 2.25.1 > > > > > -- > Thanks, > ~Nick Desaulniers >