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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 35D68C19F2A for ; Thu, 4 Aug 2022 19:25:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237748AbiHDTZG (ORCPT ); Thu, 4 Aug 2022 15:25:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34642 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232042AbiHDTZE (ORCPT ); Thu, 4 Aug 2022 15:25:04 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 83A755FAE7 for ; Thu, 4 Aug 2022 12:25:02 -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 ams.source.kernel.org (Postfix) with ESMTPS id 4ED36B82717 for ; Thu, 4 Aug 2022 19:25:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1283BC43470 for ; Thu, 4 Aug 2022 19:25:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1659641100; bh=PKX3OoDI0cvLHiN780Nvx2XfYPSh7QWOyU5r9fo/tus=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Anr99FS/HhGiIMrQZqHjDTucQNYDYxoLB9XFxLjXEW60m622qaWVtRpAjd1F/rgMT 3hZwi14NKFQlm/5pGx8ABy6YvrvYkNq5lSiZaMBNNwIBbwKqKclGzCXcYJBHkc02ZP NnQwbheBjHBH867YJPQEGGcpUNc6AvAdHUyyenFmgJZQOsfmpZULJDAb8M3dPM17lU 7Gm5/z87SY9KhsZhJ8lST7FlQxOxYTEPZ8Ev1Yu0jm6zeMteXpgaCykQaj1v093C1y ofwyPth9JXp3z40dtBiqu7iT6cXFjsi6dV3h2kB+aq166c4Zm3XjGV5UOIEA7SFZyO ShfrU7hMNMAUw== Received: by mail-wr1-f53.google.com with SMTP id z16so836497wrh.12 for ; Thu, 04 Aug 2022 12:24:59 -0700 (PDT) X-Gm-Message-State: ACgBeo2Hn4+qLcBxQPZ2S/2ri056qghALGeGHtBVlHqiisoX4mbyFV+N z5THzYnj31+I5bqbn8yBppyOY5VuVzUzdzuLHPI= X-Google-Smtp-Source: AA6agR5nJ8kOJ1KsbpBldJLoYbuUk4aeTJu478vDdBOLaBoPdwWyuN8lPQSm1sEovhlpc7uIzGpM5Z7/XraejW/ifUo= X-Received: by 2002:a5d:6489:0:b0:220:6399:c7c8 with SMTP id o9-20020a5d6489000000b002206399c7c8mr2365846wri.655.1659641098259; Thu, 04 Aug 2022 12:24:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Arnd Bergmann Date: Thu, 4 Aug 2022 21:24:41 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: mainline build failure for x86_64 allmodconfig with clang To: Linus Torvalds Cc: "Sudip Mukherjee (Codethink)" , Nathan Chancellor , clang-built-linux , Alex Deucher , =?UTF-8?Q?Christian_K=C3=B6nig?= , "Pan, Xinhui" , David Airlie , Daniel Vetter , amd-gfx list , dri-devel , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? 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. 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. Arnd