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 986A62F35 for ; Thu, 4 Aug 2022 20:43:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9AF40C433D6; Thu, 4 Aug 2022 20:43:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1659645825; bh=/dBnGEelz0eNZ7ash2KCkOnK42Kq3O9zA1e57MIkXCU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=juU3p2LUjcxjMlM6vTTY1lLZWVXb/mcsQMqGkZ/WHOsek7V0hDFsZrX6Fy+36KdAL yn6BDe8wUhOCTy+9ZmfJBWS+mP62dLFKmdwlOlB9vlElBwclJg+RepYpdf+Rh/Cr1R u1r3hEtJJAPuVVjBIr5FfU5oSiL0TI8wqQ8BHsU7AMGN+99rp1KPkm9Dpm3bncEXmC lYPlURhbpMy9WqPtn0SPIKyz/PKWa3k6Nr+SvcKaVd542jSA8LDJaEgGIFbA2AG+zj aP9g14qRKxapm+F0brNeG0LRJa69nTT/49cOFbDE96HEXU1PPAUMgBawRt2tazl2La ZP/6K+bDSkX/w== Date: Thu, 4 Aug 2022 13:43:42 -0700 From: Nathan Chancellor To: Arnd Bergmann Cc: Linus Torvalds , "Sudip Mukherjee (Codethink)" , clang-built-linux , Alex Deucher , Christian =?iso-8859-1?Q?K=F6nig?= , "Pan, Xinhui" , David Airlie , Daniel Vetter , amd-gfx list , dri-devel , Linux Kernel Mailing List Subject: Re: mainline build failure for x86_64 allmodconfig with clang Message-ID: References: Precedence: bulk X-Mailing-List: llvm@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 Thu, Aug 04, 2022 at 09:24:41PM +0200, Arnd Bergmann wrote: > On Thu, Aug 4, 2022 at 8:52 PM Linus Torvalds > wrote: > > > > On Thu, Aug 4, 2022 at 11:37 AM Sudip Mukherjee (Codethink) > > wrote:cov_trace_cmp > > > > > > git bisect points to 3876a8b5e241 ("drm/amd/display: Enable building new display engine with KCOV enabled"). > > > > Ahh. So that was presumably why it was disabled before - because it > > presumably does disgusting things that make KCOV generate even bigger > > stack frames than it already has. > > > > Those functions do seem to have fairly big stack footprints already (I > > didn't try to look into why, I assume it's partly due to aggressive > > inlining, and probably some automatic structures on stack). But gcc > > doesn't seem to make it all that much worse with KCOV (and my clang > > build doesn't enable KCOV). > > > > So it's presumably some KCOV-vs-clang thing. Nathan? Looks like Arnd beat me to it :) > The dependency was originally added to avoid a link failure in 9d1d02ff3678 > ("drm/amd/display: Don't build DCN1 when kcov is enabled") after I reported the > problem in https://lists.freedesktop.org/archives/dri-devel/2018-August/186131.html > > The commit from the bisection just turns off KCOV for the entire directory > to avoid the link failure, so it's not actually a problem with KCOV vs clang, > but I think a problem with clang vs badly written code that was obscured > in allmodconfig builds prior to this. Right, I do think the sanitizers make things worse here too, as those get enabled with allmodconfig. I ran some really quick tests with allmodconfig and a few instrumentation options flipped on/off: allmodconfig (CONFIG_KASAN=y, CONFIG_KCSAN=n, CONFIG_KCOV=y, and CONFIG_UBSAN=y): warning: stack frame size (2216) exceeds limit (2048) in 'dml30_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] warning: stack frame size (2184) exceeds limit (2048) in 'dml31_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] warning: stack frame size (2176) exceeds limit (2048) in 'dml32_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] allmodconfig + CONFIG_KASAN=n: warning: stack frame size (2112) exceeds limit (2048) in 'dml32_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] allmodconfig + CONFIG_KCOV=n: warning: stack frame size (2216) exceeds limit (2048) in 'dml30_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] warning: stack frame size (2184) exceeds limit (2048) in 'dml31_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] warning: stack frame size (2176) exceeds limit (2048) in 'dml32_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] allmodconfig + CONFIG_UBSAN=n: warning: stack frame size (2584) exceeds limit (2048) in 'dml30_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] warning: stack frame size (2680) exceeds limit (2048) in 'dml31_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] warning: stack frame size (2352) exceeds limit (2048) in 'dml32_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] allmodconfig + CONFIG_KASAN=n + CONFIG_KCSAN=y + CONFIG_UBSAN=n: warning: stack frame size (2504) exceeds limit (2048) in 'dml30_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] warning: stack frame size (2600) exceeds limit (2048) in 'dml31_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] warning: stack frame size (2264) exceeds limit (2048) in 'dml32_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] allmodconfig + CONFIG_KASAN=n + CONFIG_KCSAN=n + CONFIG_UBSAN=n: warning: stack frame size (2072) exceeds limit (2048) in 'dml31_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] There might be other debugging configurations that make this worse too, as I don't see those warnings on my distribution configuration. > The dml30_ModeSupportAndSystemConfigurationFull() function exercises > a few paths in the compiler that are otherwise rare. On thing it does is to > pass up to 60 arguments to other functions, and it heavily uses float and > double variables. Both of these make it rather fragile when it comes to > unusual compiler options, so the files keep coming up whenever a new > instrumentation feature gets added. There is probably some other flag > in allmodconfig that we can disable to improve this again, but I have not > checked this time. I do notice that these files build with a non-configurable -Wframe-large-than value: $ rg frame_warn_flag drivers/gpu/drm/amd/display/dc/dml/Makefile 54:frame_warn_flag := -Wframe-larger-than=2048 70:CFLAGS_$(AMDDALPATH)/dc/dml/dcn30/display_mode_vba_30.o := $(dml_ccflags) $(frame_warn_flag) 72:CFLAGS_$(AMDDALPATH)/dc/dml/dcn31/display_mode_vba_31.o := $(dml_ccflags) $(frame_warn_flag) 76:CFLAGS_$(AMDDALPATH)/dc/dml/dcn32/display_mode_vba_32.o := $(dml_ccflags) $(frame_warn_flag) I suppose that could just be bumped as a quick workaround? Two of those files have a comment that implies modifying them in non-trivial ways is not recommended. /* * NOTE: * This file is gcc-parsable HW gospel, coming straight from HW engineers. * * It doesn't adhere to Linux kernel style and sometimes will do things in odd * ways. Unless there is something clearly wrong with it the code should * remain as-is as it provides us with a guarantee from HW that it is correct. */ I do note that commit 1b54a0121dba ("drm/amd/display: Reduce stack size in the mode support function") did have a workaround for GCC. It appears clang will still inline mode_support_configuration(). If I mark it as 'noinline', the warning disappears in that file. 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 A9308C25B06 for ; Thu, 4 Aug 2022 20:49:42 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 38D7FA71AE; Thu, 4 Aug 2022 20:43:58 +0000 (UTC) Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by gabe.freedesktop.org (Postfix) with ESMTPS id 9FB63A700C; Thu, 4 Aug 2022 20:43:46 +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 D70426178F; Thu, 4 Aug 2022 20:43:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9AF40C433D6; Thu, 4 Aug 2022 20:43:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1659645825; bh=/dBnGEelz0eNZ7ash2KCkOnK42Kq3O9zA1e57MIkXCU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=juU3p2LUjcxjMlM6vTTY1lLZWVXb/mcsQMqGkZ/WHOsek7V0hDFsZrX6Fy+36KdAL yn6BDe8wUhOCTy+9ZmfJBWS+mP62dLFKmdwlOlB9vlElBwclJg+RepYpdf+Rh/Cr1R u1r3hEtJJAPuVVjBIr5FfU5oSiL0TI8wqQ8BHsU7AMGN+99rp1KPkm9Dpm3bncEXmC lYPlURhbpMy9WqPtn0SPIKyz/PKWa3k6Nr+SvcKaVd542jSA8LDJaEgGIFbA2AG+zj aP9g14qRKxapm+F0brNeG0LRJa69nTT/49cOFbDE96HEXU1PPAUMgBawRt2tazl2La ZP/6K+bDSkX/w== Date: Thu, 4 Aug 2022 13:43:42 -0700 From: Nathan Chancellor To: Arnd Bergmann Subject: Re: mainline build failure for x86_64 allmodconfig with clang Message-ID: References: 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: clang-built-linux , David Airlie , "Pan, Xinhui" , Linux Kernel Mailing List , amd-gfx list , Christian =?iso-8859-1?Q?K=F6nig?= , dri-devel , Alex Deucher , Linus Torvalds , "Sudip Mukherjee \(Codethink\)" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Thu, Aug 04, 2022 at 09:24:41PM +0200, Arnd Bergmann wrote: > On Thu, Aug 4, 2022 at 8:52 PM Linus Torvalds > wrote: > > > > On Thu, Aug 4, 2022 at 11:37 AM Sudip Mukherjee (Codethink) > > wrote:cov_trace_cmp > > > > > > git bisect points to 3876a8b5e241 ("drm/amd/display: Enable building new display engine with KCOV enabled"). > > > > Ahh. So that was presumably why it was disabled before - because it > > presumably does disgusting things that make KCOV generate even bigger > > stack frames than it already has. > > > > Those functions do seem to have fairly big stack footprints already (I > > didn't try to look into why, I assume it's partly due to aggressive > > inlining, and probably some automatic structures on stack). But gcc > > doesn't seem to make it all that much worse with KCOV (and my clang > > build doesn't enable KCOV). > > > > So it's presumably some KCOV-vs-clang thing. Nathan? Looks like Arnd beat me to it :) > The dependency was originally added to avoid a link failure in 9d1d02ff3678 > ("drm/amd/display: Don't build DCN1 when kcov is enabled") after I reported the > problem in https://lists.freedesktop.org/archives/dri-devel/2018-August/186131.html > > The commit from the bisection just turns off KCOV for the entire directory > to avoid the link failure, so it's not actually a problem with KCOV vs clang, > but I think a problem with clang vs badly written code that was obscured > in allmodconfig builds prior to this. Right, I do think the sanitizers make things worse here too, as those get enabled with allmodconfig. I ran some really quick tests with allmodconfig and a few instrumentation options flipped on/off: allmodconfig (CONFIG_KASAN=y, CONFIG_KCSAN=n, CONFIG_KCOV=y, and CONFIG_UBSAN=y): warning: stack frame size (2216) exceeds limit (2048) in 'dml30_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] warning: stack frame size (2184) exceeds limit (2048) in 'dml31_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] warning: stack frame size (2176) exceeds limit (2048) in 'dml32_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] allmodconfig + CONFIG_KASAN=n: warning: stack frame size (2112) exceeds limit (2048) in 'dml32_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] allmodconfig + CONFIG_KCOV=n: warning: stack frame size (2216) exceeds limit (2048) in 'dml30_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] warning: stack frame size (2184) exceeds limit (2048) in 'dml31_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] warning: stack frame size (2176) exceeds limit (2048) in 'dml32_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] allmodconfig + CONFIG_UBSAN=n: warning: stack frame size (2584) exceeds limit (2048) in 'dml30_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] warning: stack frame size (2680) exceeds limit (2048) in 'dml31_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] warning: stack frame size (2352) exceeds limit (2048) in 'dml32_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] allmodconfig + CONFIG_KASAN=n + CONFIG_KCSAN=y + CONFIG_UBSAN=n: warning: stack frame size (2504) exceeds limit (2048) in 'dml30_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] warning: stack frame size (2600) exceeds limit (2048) in 'dml31_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] warning: stack frame size (2264) exceeds limit (2048) in 'dml32_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] allmodconfig + CONFIG_KASAN=n + CONFIG_KCSAN=n + CONFIG_UBSAN=n: warning: stack frame size (2072) exceeds limit (2048) in 'dml31_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] There might be other debugging configurations that make this worse too, as I don't see those warnings on my distribution configuration. > The dml30_ModeSupportAndSystemConfigurationFull() function exercises > a few paths in the compiler that are otherwise rare. On thing it does is to > pass up to 60 arguments to other functions, and it heavily uses float and > double variables. Both of these make it rather fragile when it comes to > unusual compiler options, so the files keep coming up whenever a new > instrumentation feature gets added. There is probably some other flag > in allmodconfig that we can disable to improve this again, but I have not > checked this time. I do notice that these files build with a non-configurable -Wframe-large-than value: $ rg frame_warn_flag drivers/gpu/drm/amd/display/dc/dml/Makefile 54:frame_warn_flag := -Wframe-larger-than=2048 70:CFLAGS_$(AMDDALPATH)/dc/dml/dcn30/display_mode_vba_30.o := $(dml_ccflags) $(frame_warn_flag) 72:CFLAGS_$(AMDDALPATH)/dc/dml/dcn31/display_mode_vba_31.o := $(dml_ccflags) $(frame_warn_flag) 76:CFLAGS_$(AMDDALPATH)/dc/dml/dcn32/display_mode_vba_32.o := $(dml_ccflags) $(frame_warn_flag) I suppose that could just be bumped as a quick workaround? Two of those files have a comment that implies modifying them in non-trivial ways is not recommended. /* * NOTE: * This file is gcc-parsable HW gospel, coming straight from HW engineers. * * It doesn't adhere to Linux kernel style and sometimes will do things in odd * ways. Unless there is something clearly wrong with it the code should * remain as-is as it provides us with a guarantee from HW that it is correct. */ I do note that commit 1b54a0121dba ("drm/amd/display: Reduce stack size in the mode support function") did have a workaround for GCC. It appears clang will still inline mode_support_configuration(). If I mark it as 'noinline', the warning disappears in that file. 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 B7CCFC25B06 for ; Thu, 4 Aug 2022 20:49:48 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id C67CCA71B1; Thu, 4 Aug 2022 20:44:01 +0000 (UTC) Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by gabe.freedesktop.org (Postfix) with ESMTPS id 9FB63A700C; Thu, 4 Aug 2022 20:43:46 +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 D70426178F; Thu, 4 Aug 2022 20:43:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9AF40C433D6; Thu, 4 Aug 2022 20:43:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1659645825; bh=/dBnGEelz0eNZ7ash2KCkOnK42Kq3O9zA1e57MIkXCU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=juU3p2LUjcxjMlM6vTTY1lLZWVXb/mcsQMqGkZ/WHOsek7V0hDFsZrX6Fy+36KdAL yn6BDe8wUhOCTy+9ZmfJBWS+mP62dLFKmdwlOlB9vlElBwclJg+RepYpdf+Rh/Cr1R u1r3hEtJJAPuVVjBIr5FfU5oSiL0TI8wqQ8BHsU7AMGN+99rp1KPkm9Dpm3bncEXmC lYPlURhbpMy9WqPtn0SPIKyz/PKWa3k6Nr+SvcKaVd542jSA8LDJaEgGIFbA2AG+zj aP9g14qRKxapm+F0brNeG0LRJa69nTT/49cOFbDE96HEXU1PPAUMgBawRt2tazl2La ZP/6K+bDSkX/w== Date: Thu, 4 Aug 2022 13:43:42 -0700 From: Nathan Chancellor To: Arnd Bergmann Subject: Re: mainline build failure for x86_64 allmodconfig with clang Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: amd-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion list for AMD gfx List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: clang-built-linux , David Airlie , "Pan, Xinhui" , Linux Kernel Mailing List , amd-gfx list , Christian =?iso-8859-1?Q?K=F6nig?= , dri-devel , Daniel Vetter , Alex Deucher , Linus Torvalds , "Sudip Mukherjee \(Codethink\)" Errors-To: amd-gfx-bounces@lists.freedesktop.org Sender: "amd-gfx" On Thu, Aug 04, 2022 at 09:24:41PM +0200, Arnd Bergmann wrote: > On Thu, Aug 4, 2022 at 8:52 PM Linus Torvalds > wrote: > > > > On Thu, Aug 4, 2022 at 11:37 AM Sudip Mukherjee (Codethink) > > wrote:cov_trace_cmp > > > > > > git bisect points to 3876a8b5e241 ("drm/amd/display: Enable building new display engine with KCOV enabled"). > > > > Ahh. So that was presumably why it was disabled before - because it > > presumably does disgusting things that make KCOV generate even bigger > > stack frames than it already has. > > > > Those functions do seem to have fairly big stack footprints already (I > > didn't try to look into why, I assume it's partly due to aggressive > > inlining, and probably some automatic structures on stack). But gcc > > doesn't seem to make it all that much worse with KCOV (and my clang > > build doesn't enable KCOV). > > > > So it's presumably some KCOV-vs-clang thing. Nathan? Looks like Arnd beat me to it :) > The dependency was originally added to avoid a link failure in 9d1d02ff3678 > ("drm/amd/display: Don't build DCN1 when kcov is enabled") after I reported the > problem in https://lists.freedesktop.org/archives/dri-devel/2018-August/186131.html > > The commit from the bisection just turns off KCOV for the entire directory > to avoid the link failure, so it's not actually a problem with KCOV vs clang, > but I think a problem with clang vs badly written code that was obscured > in allmodconfig builds prior to this. Right, I do think the sanitizers make things worse here too, as those get enabled with allmodconfig. I ran some really quick tests with allmodconfig and a few instrumentation options flipped on/off: allmodconfig (CONFIG_KASAN=y, CONFIG_KCSAN=n, CONFIG_KCOV=y, and CONFIG_UBSAN=y): warning: stack frame size (2216) exceeds limit (2048) in 'dml30_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] warning: stack frame size (2184) exceeds limit (2048) in 'dml31_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] warning: stack frame size (2176) exceeds limit (2048) in 'dml32_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] allmodconfig + CONFIG_KASAN=n: warning: stack frame size (2112) exceeds limit (2048) in 'dml32_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] allmodconfig + CONFIG_KCOV=n: warning: stack frame size (2216) exceeds limit (2048) in 'dml30_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] warning: stack frame size (2184) exceeds limit (2048) in 'dml31_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] warning: stack frame size (2176) exceeds limit (2048) in 'dml32_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] allmodconfig + CONFIG_UBSAN=n: warning: stack frame size (2584) exceeds limit (2048) in 'dml30_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] warning: stack frame size (2680) exceeds limit (2048) in 'dml31_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] warning: stack frame size (2352) exceeds limit (2048) in 'dml32_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] allmodconfig + CONFIG_KASAN=n + CONFIG_KCSAN=y + CONFIG_UBSAN=n: warning: stack frame size (2504) exceeds limit (2048) in 'dml30_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] warning: stack frame size (2600) exceeds limit (2048) in 'dml31_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] warning: stack frame size (2264) exceeds limit (2048) in 'dml32_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] allmodconfig + CONFIG_KASAN=n + CONFIG_KCSAN=n + CONFIG_UBSAN=n: warning: stack frame size (2072) exceeds limit (2048) in 'dml31_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] There might be other debugging configurations that make this worse too, as I don't see those warnings on my distribution configuration. > The dml30_ModeSupportAndSystemConfigurationFull() function exercises > a few paths in the compiler that are otherwise rare. On thing it does is to > pass up to 60 arguments to other functions, and it heavily uses float and > double variables. Both of these make it rather fragile when it comes to > unusual compiler options, so the files keep coming up whenever a new > instrumentation feature gets added. There is probably some other flag > in allmodconfig that we can disable to improve this again, but I have not > checked this time. I do notice that these files build with a non-configurable -Wframe-large-than value: $ rg frame_warn_flag drivers/gpu/drm/amd/display/dc/dml/Makefile 54:frame_warn_flag := -Wframe-larger-than=2048 70:CFLAGS_$(AMDDALPATH)/dc/dml/dcn30/display_mode_vba_30.o := $(dml_ccflags) $(frame_warn_flag) 72:CFLAGS_$(AMDDALPATH)/dc/dml/dcn31/display_mode_vba_31.o := $(dml_ccflags) $(frame_warn_flag) 76:CFLAGS_$(AMDDALPATH)/dc/dml/dcn32/display_mode_vba_32.o := $(dml_ccflags) $(frame_warn_flag) I suppose that could just be bumped as a quick workaround? Two of those files have a comment that implies modifying them in non-trivial ways is not recommended. /* * NOTE: * This file is gcc-parsable HW gospel, coming straight from HW engineers. * * It doesn't adhere to Linux kernel style and sometimes will do things in odd * ways. Unless there is something clearly wrong with it the code should * remain as-is as it provides us with a guarantee from HW that it is correct. */ I do note that commit 1b54a0121dba ("drm/amd/display: Reduce stack size in the mode support function") did have a workaround for GCC. It appears clang will still inline mode_support_configuration(). If I mark it as 'noinline', the warning disappears in that file. Cheers, Nathan