From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by mx.groups.io with SMTP id smtpd.web11.68062.1680522937183967789 for ; Mon, 03 Apr 2023 04:55:37 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=KhRErIUR; spf=pass (domain: kernel.org, ip: 145.40.68.75, mailfrom: ardb@kernel.org) 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 27A5FB81915 for ; Mon, 3 Apr 2023 11:55:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 759EEC433A8 for ; Mon, 3 Apr 2023 11:55:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1680522933; bh=p900lsqhYCINj48DGbMLqUuJBdW9CX69Ftf3UhAkj9E=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=KhRErIURJ61TCULLYoAA0gFM1qzT6V/GLE9kgnT6UCNNXdZtg9R8z8l8RdR95OydT v5hq0UnTBphtyf+mBPDtEqxbUBqRLLPGxcRuZO11EfEPcwB8JSuW0/2wCkSZCf9Jk2 vjD49WKWMQA0wznv5pIggJAqneChC30V8LJnDkliOttUjKcpvVldGBiBUWdMZfrUZk YE7Jssqx6coozM2O323gIynuhM9bv1z02Rho+Be1ADGWu70yy7YetYMmiiVxtnjpOg qawr2hLNQrrnplBbfdwLuWq4ebAyxz9NakMhIqPKx20Npvo1J1WEg1sdsYZrkvhTqS lGqkh6hXOVh1g== Received: by mail-lf1-f45.google.com with SMTP id br6so37682027lfb.11 for ; Mon, 03 Apr 2023 04:55:33 -0700 (PDT) X-Gm-Message-State: AAQBX9eesTTlN1lCIEkd6U6hTam/4Sw9ZjEaRsAa1lCX8Z+9MR9X0SOQ s8vkS1LUcePehZjzswzx2TL6WM3lxdVQw2MwiX8= X-Google-Smtp-Source: AKy350bczxcEtHdIvVMKmHBw9v8uYEIlmHyLhHHk2IhuwY+VXwSxiTFWhakIieW0bHgM1h/RMSHTYSUOzO6vsG8h4ZQ= X-Received: by 2002:ac2:568d:0:b0:4eb:c44:ed50 with SMTP id 13-20020ac2568d000000b004eb0c44ed50mr8599173lfr.9.1680522931345; Mon, 03 Apr 2023 04:55:31 -0700 (PDT) MIME-Version: 1.0 References: <20230328173111.759017-1-rebecca@bsdio.com> <02fb01d961dc$88d6acd0$9a840670$@byosoft.com.cn> <92a85636-3875-fd4d-06ff-dab9670370a5@bsdio.com> In-Reply-To: From: "Ard Biesheuvel" Date: Mon, 3 Apr 2023 13:55:19 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: =?UTF-8?B?UmU6IOWbnuWkjTogW2VkazItZGV2ZWxdIFtQQVRDSCB2MiAwMC8xM10gQmFzZVRvb2xzLENyeXB0b1BrZyxNZGVQa2csT3ZtZlBrZzogRGVsZXRlIENMQU5HMzUsQ0xBTkczOCxHQ0M0OCxHQ0M0OSwgcmVuYW1lIEdDQzUgdG8gR0NDLCB1cGRhdGUgQ0xBTkdEV0FSRiwgZGVsZXRlIFZTIDIwMDgtMjAxMywgRUJD?= To: Gerd Hoffmann Cc: devel@edk2.groups.io, rebecca@bsdio.com, Pedro Falcato , gaoliming , Oliver Smith-Denny , Guomin Jiang , Xiaoyu Lu , Jian J Wang , Jiewen Yao , Ard Biesheuvel , Jordan Justen , Bob Feng , Andrew Fish , Leif Lindholm , Michael D Kinney Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 3 Apr 2023 at 13:39, Gerd Hoffmann wrote: > > On Mon, Apr 03, 2023 at 05:33:10AM -0600, Rebecca Cran wrote: > > On 4/3/23 5:30 AM, Gerd Hoffmann wrote: > > > I'm wondering what the point in keeping a known-broken toolchain thou= gh. > > > It is apparently unused when nobody noticed the breakage ... > > > > I agree. At this point I want to reach a consensus and get this patch s= eries > > committed, even if that means leaving a known broken toolchain around. > > Sure. That question was meant more for gaoliming who expressed interest > in keeping it. gaoliming? > > I'd prefer to keep GCC only. In case we decide to keep both LTO and > non-LTO variants the GCC + GCCNOLTE naming scheme looks fine to me. > I agree that we should either support a toolchain (and have CI coverage for it) or not, in which case we should just remove it. However, the issues being reported are specific to SEV-SNP and TDX, which implies that they are specific to OVMF. And actually, the reported issue at OvmfPkg/Library/CcExitLib/CcExitVcHandler.c:1358:10: error: =E2=80=98XCr0=E2=80=99 may be used uninitialized [-Werror=3Dmaybe-un= initialized] seems to be a valid concern. So the point I am making is that OVMF gets a lot of attention in the open source project, but in the wider ecosystem, there are many platforms relying on this code base that don't incorporate the Coco components at all, so whether OVMF currently builds with GCC49 is not 100% relevant. So I am leaning towards retaining GCC49 as GCCNOLTO, and getting some coverage for it in CI, as we occasionally get useful diagnostics out of it. But I am not going to fight any battles over it - I rarely use it myself, and so I will not miss it when it's gone. Liming, are you aware of any users relying on non-LTO GCC codegen for any reason?