From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 31ABC7A; Mon, 28 Feb 2022 16:56:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A46A1C340E7; Mon, 28 Feb 2022 16:56:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1646067380; bh=523gBdVPJChXozDXmy5Cb2pK2i/xRfAcGRZVUQAHjNc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LgVJuH4da0tpuW1nX+TSzWKpqT1/5OI3uq9Url+IKydIaNvJrwxxCJ02pDsUamp0J BXgyENWeP0ucoramTVXNaT23Z6w+IPOpRsVnisqnZwdBL4ARuBusSY6JLdz3305OfE YtZvql2BfkwdTq2LxRIJRizjGmx3hngX5RBUDcSxgf2mLkssqkaZFIqarTisHboNdy Xy986yF0zeYZbw6HX61O+ecCg/MIlsoP4bKonolKYJ+91DSdYuEy6Ckl7v583fSXhJ fxInQ5iK44jGAKr2Pvl9ywk4psfT+Vv0H/AbdegLc3kV5x8iLrYBvahTmACsIjfZ5u Ol9BFIfpBb+FA== Date: Mon, 28 Feb 2022 09:56:13 -0700 From: Nathan Chancellor To: Arnd Bergmann Cc: Marco Elver , Linux Kbuild mailing list , Arnd Bergmann , Linus Torvalds , Masahiro Yamada , llvm@lists.linux.dev, Jonathan Corbet , Federico Vaga , Alex Shi , Hu Haowen , Michal Marek , Nick Desaulniers , "open list:DOCUMENTATION" , Linux Kernel Mailing List , linux-doc-tw-discuss@lists.sourceforge.net, Linux ARM , Intel Graphics , dri-devel , greybus-dev@lists.linaro.org, linux-staging@lists.linux.dev, linux-btrfs , Mark Rutland Subject: Re: [PATCH] [v2] Kbuild: move to -std=gnu11 Message-ID: References: <20220228103142.3301082-1-arnd@kernel.org> Precedence: bulk X-Mailing-List: linux-staging@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Mon, Feb 28, 2022 at 12:57:55PM +0100, Arnd Bergmann wrote: > On Mon, Feb 28, 2022 at 12:47 PM Marco Elver wrote: > > On Mon, 28 Feb 2022 at 11:32, Arnd Bergmann wrote: > > > > > Nathan Chancellor reported an additional -Wdeclaration-after-statement > > > warning that appears in a system header on arm, this still needs a > > > workaround. > > > > On the topic of Wdeclaration-after-statement, Clang only respects this > > warning with C99 and later starting with Clang 14: > > https://github.com/llvm/llvm-project/commit/c65186c89f35#diff-ec770381d76c859f5f572db789175fe44410a72608f58ad5dbb14335ba56eb97R61 > > > > Until Clang 14, -Wdeclaration-after-statement is ignored by Clang in > > newer standards. If this is a big problem, we can probably convince > > the Clang stable folks to backport the fixes. However, the build won't > > fail, folks might just miss the warning if they don't also test with > > GCC. Unfortunately, none of the branches prior to release/14.x are going to see any more updates (at least as far as I am aware, as the LLVM community only supports one release branch at a time) but as Arnd mentioned below, I do not really see that as a problem, as newer versions of clang and GCC will catch these warnings. > I don't expect this is to be a big issue, as long as the latest clang behaves > as expected. There are many warnings that are only produced by one of the > two compilers, so this is something we already deal with. > > I think it's more important to address the extra warning that Nathan > reported, where clang now complains about the intermingled declaration > in a system header when previously neither gcc nor clang noticed this. Right. Based on the upstream LLVM bug, I think we should just fix arm_neon.h to avoid triggering -Wdeclaration-after-statement to have something that is (hopefully) relatively low risk for a clang-14 backport, rather than addressing the root cause of clang warning in system macros, as it sounds like fixing that has some risks that are not fully understood at this point. The kernel only uses very specific system headers after commit 04e85bbf71c9 ("isystem: delete global -isystem compile option"), so I don't think that my suggested approach will have many downsides. I think I see how to potentially fix arm_neon.h in clang/utils/TableGen/NeonEmitter.cpp, I just have to think about it a little more. Realistically, I don't think special casing this in lib/raid6 is the end of the world: diff --git a/lib/raid6/Makefile b/lib/raid6/Makefile index 45e17619422b..a41ff71b90af 100644 --- a/lib/raid6/Makefile +++ b/lib/raid6/Makefile @@ -38,6 +38,10 @@ ifeq ($(CONFIG_KERNEL_MODE_NEON),y) NEON_FLAGS := -ffreestanding # Enable NEON_FLAGS += -isystem $(shell $(CC) -print-file-name=include) +# https://github.com/ClangBuiltLinux/linux/issues/1603 +ifeq ($(CONFIG_CC_IS_CLANG)$(CONFIG_CPU_BIG_ENDIAN),yy) +NEON_FLAGS += -Wno-declaration-after-statement +endif ifeq ($(ARCH),arm) NEON_FLAGS += -march=armv7-a -mfloat-abi=softfp -mfpu=neon endif > > > The differences between gnu99, gnu11, gnu1x and gnu17 are fairly > > > minimal and mainly impact warnings at the -Wpedantic level that the > > > kernel never enables. Between these, gnu11 is the newest version > > > that is supported by all supported compiler versions, though it is > > > only the default on gcc-5, while all other supported versions of > > > gcc or clang default to gnu1x/gnu17. > > > > > > Link: https://lore.kernel.org/lkml/CAHk-=wiyCH7xeHcmiFJ-YgXUy2Jaj7pnkdKpcovt8fYbVFW3TA@mail.gmail.com/ > > > Link: https://github.com/ClangBuiltLinux/linux/issues/1603 > > > Suggested-by: Linus Torvalds > > > Cc: Masahiro Yamada > > > Cc: linux-kbuild@vger.kernel.org > > > Cc: llvm@lists.linux.dev > > > Signed-off-by: Arnd Bergmann > > > > Acked-by: Marco Elver Cheers, Nathan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E8D1BC433EF for ; Mon, 28 Feb 2022 16:57:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=6vGdTmcbmd/rU0k6Qbz2BFJrOISt6Qzb5VUWSAem83k=; b=HLv2LXB7qsI40o 6Ll9IufmTckt5K1jn2jfBohltTpELWGb953Qa4sWnpk9qDyqsLlZ8/PQ8RIC5H9skdZqfFV4WmynX wHMxZNFINDMIlxPHhc5zcYxgkiJ8DS+H5N+pYE8bvW3nWH+HQ+hdvyfidLbJ8mMIalddDRVZjMepQ 9U4tlJYRFkcNgIjSJVcNJnIk6wh/tyjhfiKuVSAv+7uu7NmJ61r8J0gGdDEYBpe7d4aEWLTz7jnqI RKQ7NL66LWd1hlWah3IY3H+eieSyzNh4z+xrEUrYS3U/ig3PtnfeWubXicp3BFF/24Lljgwy4cE9M x2ZDq2FJwPwTaUuxShNg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nOjJz-00DPip-A3; Mon, 28 Feb 2022 16:56:27 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nOjJu-00DPh1-QH for linux-arm-kernel@lists.infradead.org; Mon, 28 Feb 2022 16:56:24 +0000 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 6B6F461266; Mon, 28 Feb 2022 16:56:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A46A1C340E7; Mon, 28 Feb 2022 16:56:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1646067380; bh=523gBdVPJChXozDXmy5Cb2pK2i/xRfAcGRZVUQAHjNc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LgVJuH4da0tpuW1nX+TSzWKpqT1/5OI3uq9Url+IKydIaNvJrwxxCJ02pDsUamp0J BXgyENWeP0ucoramTVXNaT23Z6w+IPOpRsVnisqnZwdBL4ARuBusSY6JLdz3305OfE YtZvql2BfkwdTq2LxRIJRizjGmx3hngX5RBUDcSxgf2mLkssqkaZFIqarTisHboNdy Xy986yF0zeYZbw6HX61O+ecCg/MIlsoP4bKonolKYJ+91DSdYuEy6Ckl7v583fSXhJ fxInQ5iK44jGAKr2Pvl9ywk4psfT+Vv0H/AbdegLc3kV5x8iLrYBvahTmACsIjfZ5u Ol9BFIfpBb+FA== Date: Mon, 28 Feb 2022 09:56:13 -0700 From: Nathan Chancellor To: Arnd Bergmann Cc: Marco Elver , Linux Kbuild mailing list , Arnd Bergmann , Linus Torvalds , Masahiro Yamada , llvm@lists.linux.dev, Jonathan Corbet , Federico Vaga , Alex Shi , Hu Haowen , Michal Marek , Nick Desaulniers , "open list:DOCUMENTATION" , Linux Kernel Mailing List , linux-doc-tw-discuss@lists.sourceforge.net, Linux ARM , Intel Graphics , dri-devel , greybus-dev@lists.linaro.org, linux-staging@lists.linux.dev, linux-btrfs , Mark Rutland Subject: Re: [PATCH] [v2] Kbuild: move to -std=gnu11 Message-ID: References: <20220228103142.3301082-1-arnd@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220228_085622_979367_C193BA1E X-CRM114-Status: GOOD ( 32.52 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Feb 28, 2022 at 12:57:55PM +0100, Arnd Bergmann wrote: > On Mon, Feb 28, 2022 at 12:47 PM Marco Elver wrote: > > On Mon, 28 Feb 2022 at 11:32, Arnd Bergmann wrote: > > > > > Nathan Chancellor reported an additional -Wdeclaration-after-statement > > > warning that appears in a system header on arm, this still needs a > > > workaround. > > > > On the topic of Wdeclaration-after-statement, Clang only respects this > > warning with C99 and later starting with Clang 14: > > https://github.com/llvm/llvm-project/commit/c65186c89f35#diff-ec770381d76c859f5f572db789175fe44410a72608f58ad5dbb14335ba56eb97R61 > > > > Until Clang 14, -Wdeclaration-after-statement is ignored by Clang in > > newer standards. If this is a big problem, we can probably convince > > the Clang stable folks to backport the fixes. However, the build won't > > fail, folks might just miss the warning if they don't also test with > > GCC. Unfortunately, none of the branches prior to release/14.x are going to see any more updates (at least as far as I am aware, as the LLVM community only supports one release branch at a time) but as Arnd mentioned below, I do not really see that as a problem, as newer versions of clang and GCC will catch these warnings. > I don't expect this is to be a big issue, as long as the latest clang behaves > as expected. There are many warnings that are only produced by one of the > two compilers, so this is something we already deal with. > > I think it's more important to address the extra warning that Nathan > reported, where clang now complains about the intermingled declaration > in a system header when previously neither gcc nor clang noticed this. Right. Based on the upstream LLVM bug, I think we should just fix arm_neon.h to avoid triggering -Wdeclaration-after-statement to have something that is (hopefully) relatively low risk for a clang-14 backport, rather than addressing the root cause of clang warning in system macros, as it sounds like fixing that has some risks that are not fully understood at this point. The kernel only uses very specific system headers after commit 04e85bbf71c9 ("isystem: delete global -isystem compile option"), so I don't think that my suggested approach will have many downsides. I think I see how to potentially fix arm_neon.h in clang/utils/TableGen/NeonEmitter.cpp, I just have to think about it a little more. Realistically, I don't think special casing this in lib/raid6 is the end of the world: diff --git a/lib/raid6/Makefile b/lib/raid6/Makefile index 45e17619422b..a41ff71b90af 100644 --- a/lib/raid6/Makefile +++ b/lib/raid6/Makefile @@ -38,6 +38,10 @@ ifeq ($(CONFIG_KERNEL_MODE_NEON),y) NEON_FLAGS := -ffreestanding # Enable NEON_FLAGS += -isystem $(shell $(CC) -print-file-name=include) +# https://github.com/ClangBuiltLinux/linux/issues/1603 +ifeq ($(CONFIG_CC_IS_CLANG)$(CONFIG_CPU_BIG_ENDIAN),yy) +NEON_FLAGS += -Wno-declaration-after-statement +endif ifeq ($(ARCH),arm) NEON_FLAGS += -march=armv7-a -mfloat-abi=softfp -mfpu=neon endif > > > The differences between gnu99, gnu11, gnu1x and gnu17 are fairly > > > minimal and mainly impact warnings at the -Wpedantic level that the > > > kernel never enables. Between these, gnu11 is the newest version > > > that is supported by all supported compiler versions, though it is > > > only the default on gcc-5, while all other supported versions of > > > gcc or clang default to gnu1x/gnu17. > > > > > > Link: https://lore.kernel.org/lkml/CAHk-=wiyCH7xeHcmiFJ-YgXUy2Jaj7pnkdKpcovt8fYbVFW3TA@mail.gmail.com/ > > > Link: https://github.com/ClangBuiltLinux/linux/issues/1603 > > > Suggested-by: Linus Torvalds > > > Cc: Masahiro Yamada > > > Cc: linux-kbuild@vger.kernel.org > > > Cc: llvm@lists.linux.dev > > > Signed-off-by: Arnd Bergmann > > > > Acked-by: Marco Elver Cheers, Nathan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A4A0AC4332F for ; Mon, 28 Feb 2022 16:56:25 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 9508310E17F; Mon, 28 Feb 2022 16:56:24 +0000 (UTC) Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by gabe.freedesktop.org (Postfix) with ESMTPS id 8577910E17F; Mon, 28 Feb 2022 16:56:23 +0000 (UTC) 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 6B6F461266; Mon, 28 Feb 2022 16:56:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A46A1C340E7; Mon, 28 Feb 2022 16:56:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1646067380; bh=523gBdVPJChXozDXmy5Cb2pK2i/xRfAcGRZVUQAHjNc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LgVJuH4da0tpuW1nX+TSzWKpqT1/5OI3uq9Url+IKydIaNvJrwxxCJ02pDsUamp0J BXgyENWeP0ucoramTVXNaT23Z6w+IPOpRsVnisqnZwdBL4ARuBusSY6JLdz3305OfE YtZvql2BfkwdTq2LxRIJRizjGmx3hngX5RBUDcSxgf2mLkssqkaZFIqarTisHboNdy Xy986yF0zeYZbw6HX61O+ecCg/MIlsoP4bKonolKYJ+91DSdYuEy6Ckl7v583fSXhJ fxInQ5iK44jGAKr2Pvl9ywk4psfT+Vv0H/AbdegLc3kV5x8iLrYBvahTmACsIjfZ5u Ol9BFIfpBb+FA== Date: Mon, 28 Feb 2022 09:56:13 -0700 From: Nathan Chancellor To: Arnd Bergmann Subject: Re: [PATCH] [v2] Kbuild: move to -std=gnu11 Message-ID: References: <20220228103142.3301082-1-arnd@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , "open list:DOCUMENTATION" , llvm@lists.linux.dev, dri-devel , Alex Shi , Jonathan Corbet , Masahiro Yamada , linux-staging@lists.linux.dev, Federico Vaga , Marco Elver , Arnd Bergmann , Linux Kbuild mailing list , Intel Graphics , greybus-dev@lists.linaro.org, Linux ARM , Michal Marek , Hu Haowen , linux-doc-tw-discuss@lists.sourceforge.net, Nick Desaulniers , Linux Kernel Mailing List , Linus Torvalds , linux-btrfs Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Mon, Feb 28, 2022 at 12:57:55PM +0100, Arnd Bergmann wrote: > On Mon, Feb 28, 2022 at 12:47 PM Marco Elver wrote: > > On Mon, 28 Feb 2022 at 11:32, Arnd Bergmann wrote: > > > > > Nathan Chancellor reported an additional -Wdeclaration-after-statement > > > warning that appears in a system header on arm, this still needs a > > > workaround. > > > > On the topic of Wdeclaration-after-statement, Clang only respects this > > warning with C99 and later starting with Clang 14: > > https://github.com/llvm/llvm-project/commit/c65186c89f35#diff-ec770381d76c859f5f572db789175fe44410a72608f58ad5dbb14335ba56eb97R61 > > > > Until Clang 14, -Wdeclaration-after-statement is ignored by Clang in > > newer standards. If this is a big problem, we can probably convince > > the Clang stable folks to backport the fixes. However, the build won't > > fail, folks might just miss the warning if they don't also test with > > GCC. Unfortunately, none of the branches prior to release/14.x are going to see any more updates (at least as far as I am aware, as the LLVM community only supports one release branch at a time) but as Arnd mentioned below, I do not really see that as a problem, as newer versions of clang and GCC will catch these warnings. > I don't expect this is to be a big issue, as long as the latest clang behaves > as expected. There are many warnings that are only produced by one of the > two compilers, so this is something we already deal with. > > I think it's more important to address the extra warning that Nathan > reported, where clang now complains about the intermingled declaration > in a system header when previously neither gcc nor clang noticed this. Right. Based on the upstream LLVM bug, I think we should just fix arm_neon.h to avoid triggering -Wdeclaration-after-statement to have something that is (hopefully) relatively low risk for a clang-14 backport, rather than addressing the root cause of clang warning in system macros, as it sounds like fixing that has some risks that are not fully understood at this point. The kernel only uses very specific system headers after commit 04e85bbf71c9 ("isystem: delete global -isystem compile option"), so I don't think that my suggested approach will have many downsides. I think I see how to potentially fix arm_neon.h in clang/utils/TableGen/NeonEmitter.cpp, I just have to think about it a little more. Realistically, I don't think special casing this in lib/raid6 is the end of the world: diff --git a/lib/raid6/Makefile b/lib/raid6/Makefile index 45e17619422b..a41ff71b90af 100644 --- a/lib/raid6/Makefile +++ b/lib/raid6/Makefile @@ -38,6 +38,10 @@ ifeq ($(CONFIG_KERNEL_MODE_NEON),y) NEON_FLAGS := -ffreestanding # Enable NEON_FLAGS += -isystem $(shell $(CC) -print-file-name=include) +# https://github.com/ClangBuiltLinux/linux/issues/1603 +ifeq ($(CONFIG_CC_IS_CLANG)$(CONFIG_CPU_BIG_ENDIAN),yy) +NEON_FLAGS += -Wno-declaration-after-statement +endif ifeq ($(ARCH),arm) NEON_FLAGS += -march=armv7-a -mfloat-abi=softfp -mfpu=neon endif > > > The differences between gnu99, gnu11, gnu1x and gnu17 are fairly > > > minimal and mainly impact warnings at the -Wpedantic level that the > > > kernel never enables. Between these, gnu11 is the newest version > > > that is supported by all supported compiler versions, though it is > > > only the default on gcc-5, while all other supported versions of > > > gcc or clang default to gnu1x/gnu17. > > > > > > Link: https://lore.kernel.org/lkml/CAHk-=wiyCH7xeHcmiFJ-YgXUy2Jaj7pnkdKpcovt8fYbVFW3TA@mail.gmail.com/ > > > Link: https://github.com/ClangBuiltLinux/linux/issues/1603 > > > Suggested-by: Linus Torvalds > > > Cc: Masahiro Yamada > > > Cc: linux-kbuild@vger.kernel.org > > > Cc: llvm@lists.linux.dev > > > Signed-off-by: Arnd Bergmann > > > > Acked-by: Marco Elver Cheers, Nathan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 2369BC433EF for ; Tue, 1 Mar 2022 09:19:24 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id F144B10E731; Tue, 1 Mar 2022 09:19:22 +0000 (UTC) Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by gabe.freedesktop.org (Postfix) with ESMTPS id 8577910E17F; Mon, 28 Feb 2022 16:56:23 +0000 (UTC) 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 6B6F461266; Mon, 28 Feb 2022 16:56:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A46A1C340E7; Mon, 28 Feb 2022 16:56:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1646067380; bh=523gBdVPJChXozDXmy5Cb2pK2i/xRfAcGRZVUQAHjNc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LgVJuH4da0tpuW1nX+TSzWKpqT1/5OI3uq9Url+IKydIaNvJrwxxCJ02pDsUamp0J BXgyENWeP0ucoramTVXNaT23Z6w+IPOpRsVnisqnZwdBL4ARuBusSY6JLdz3305OfE YtZvql2BfkwdTq2LxRIJRizjGmx3hngX5RBUDcSxgf2mLkssqkaZFIqarTisHboNdy Xy986yF0zeYZbw6HX61O+ecCg/MIlsoP4bKonolKYJ+91DSdYuEy6Ckl7v583fSXhJ fxInQ5iK44jGAKr2Pvl9ywk4psfT+Vv0H/AbdegLc3kV5x8iLrYBvahTmACsIjfZ5u Ol9BFIfpBb+FA== Date: Mon, 28 Feb 2022 09:56:13 -0700 From: Nathan Chancellor To: Arnd Bergmann Message-ID: References: <20220228103142.3301082-1-arnd@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Mailman-Approved-At: Tue, 01 Mar 2022 09:19:22 +0000 Subject: Re: [Intel-gfx] [PATCH] [v2] Kbuild: move to -std=gnu11 X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , "open list:DOCUMENTATION" , llvm@lists.linux.dev, dri-devel , Alex Shi , Jonathan Corbet , Masahiro Yamada , linux-staging@lists.linux.dev, Federico Vaga , Marco Elver , Arnd Bergmann , Linux Kbuild mailing list , Intel Graphics , greybus-dev@lists.linaro.org, Linux ARM , Michal Marek , Hu Haowen , linux-doc-tw-discuss@lists.sourceforge.net, Nick Desaulniers , Linux Kernel Mailing List , Linus Torvalds , linux-btrfs Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Mon, Feb 28, 2022 at 12:57:55PM +0100, Arnd Bergmann wrote: > On Mon, Feb 28, 2022 at 12:47 PM Marco Elver wrote: > > On Mon, 28 Feb 2022 at 11:32, Arnd Bergmann wrote: > > > > > Nathan Chancellor reported an additional -Wdeclaration-after-statement > > > warning that appears in a system header on arm, this still needs a > > > workaround. > > > > On the topic of Wdeclaration-after-statement, Clang only respects this > > warning with C99 and later starting with Clang 14: > > https://github.com/llvm/llvm-project/commit/c65186c89f35#diff-ec770381d76c859f5f572db789175fe44410a72608f58ad5dbb14335ba56eb97R61 > > > > Until Clang 14, -Wdeclaration-after-statement is ignored by Clang in > > newer standards. If this is a big problem, we can probably convince > > the Clang stable folks to backport the fixes. However, the build won't > > fail, folks might just miss the warning if they don't also test with > > GCC. Unfortunately, none of the branches prior to release/14.x are going to see any more updates (at least as far as I am aware, as the LLVM community only supports one release branch at a time) but as Arnd mentioned below, I do not really see that as a problem, as newer versions of clang and GCC will catch these warnings. > I don't expect this is to be a big issue, as long as the latest clang behaves > as expected. There are many warnings that are only produced by one of the > two compilers, so this is something we already deal with. > > I think it's more important to address the extra warning that Nathan > reported, where clang now complains about the intermingled declaration > in a system header when previously neither gcc nor clang noticed this. Right. Based on the upstream LLVM bug, I think we should just fix arm_neon.h to avoid triggering -Wdeclaration-after-statement to have something that is (hopefully) relatively low risk for a clang-14 backport, rather than addressing the root cause of clang warning in system macros, as it sounds like fixing that has some risks that are not fully understood at this point. The kernel only uses very specific system headers after commit 04e85bbf71c9 ("isystem: delete global -isystem compile option"), so I don't think that my suggested approach will have many downsides. I think I see how to potentially fix arm_neon.h in clang/utils/TableGen/NeonEmitter.cpp, I just have to think about it a little more. Realistically, I don't think special casing this in lib/raid6 is the end of the world: diff --git a/lib/raid6/Makefile b/lib/raid6/Makefile index 45e17619422b..a41ff71b90af 100644 --- a/lib/raid6/Makefile +++ b/lib/raid6/Makefile @@ -38,6 +38,10 @@ ifeq ($(CONFIG_KERNEL_MODE_NEON),y) NEON_FLAGS := -ffreestanding # Enable NEON_FLAGS += -isystem $(shell $(CC) -print-file-name=include) +# https://github.com/ClangBuiltLinux/linux/issues/1603 +ifeq ($(CONFIG_CC_IS_CLANG)$(CONFIG_CPU_BIG_ENDIAN),yy) +NEON_FLAGS += -Wno-declaration-after-statement +endif ifeq ($(ARCH),arm) NEON_FLAGS += -march=armv7-a -mfloat-abi=softfp -mfpu=neon endif > > > The differences between gnu99, gnu11, gnu1x and gnu17 are fairly > > > minimal and mainly impact warnings at the -Wpedantic level that the > > > kernel never enables. Between these, gnu11 is the newest version > > > that is supported by all supported compiler versions, though it is > > > only the default on gcc-5, while all other supported versions of > > > gcc or clang default to gnu1x/gnu17. > > > > > > Link: https://lore.kernel.org/lkml/CAHk-=wiyCH7xeHcmiFJ-YgXUy2Jaj7pnkdKpcovt8fYbVFW3TA@mail.gmail.com/ > > > Link: https://github.com/ClangBuiltLinux/linux/issues/1603 > > > Suggested-by: Linus Torvalds > > > Cc: Masahiro Yamada > > > Cc: linux-kbuild@vger.kernel.org > > > Cc: llvm@lists.linux.dev > > > Signed-off-by: Arnd Bergmann > > > > Acked-by: Marco Elver Cheers, Nathan