Are the same issue(s) found with GCC5 with -b NOOPT? Mike
> -----Original Message----- > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Ard Biesheuvel > Sent: Monday, April 3, 2023 6:05 AM > To: devel@edk2.groups.io; quic_llind...@quicinc.com > Cc: Gerd Hoffmann <kra...@redhat.com>; rebe...@bsdio.com; Pedro Falcato > <pedro.falc...@gmail.com>; Gao, Liming > <gaolim...@byosoft.com.cn>; Oliver Smith-Denny <o...@smith-denny.com>; Jiang, > Guomin <guomin.ji...@intel.com>; Lu, Xiaoyu1 > <xiaoyu1...@intel.com>; Wang, Jian J <jian.j.w...@intel.com>; Yao, Jiewen > <jiewen....@intel.com>; Ard Biesheuvel > <ardb+tianoc...@kernel.org>; Justen, Jordan L <jordan.l.jus...@intel.com>; > Feng, Bob C <bob.c.f...@intel.com>; Andrew Fish > <af...@apple.com>; Kinney, Michael D <michael.d.kin...@intel.com> > Subject: Re: 回复: [edk2-devel] [PATCH v2 00/13] > BaseTools,CryptoPkg,MdePkg,OvmfPkg: Delete CLANG35,CLANG38,GCC48,GCC49, > rename GCC5 to GCC, update CLANGDWARF, delete VS 2008-2013, EBC > > On Mon, 3 Apr 2023 at 14:15, Leif Lindholm <quic_llind...@quicinc.com> wrote: > > > > On Mon, Apr 03, 2023 at 13:55:19 +0200, Ard Biesheuvel wrote: > > > 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: ‘XCr0’ may be used uninitialized [-Werror=maybe-uninitialized] > > > > > > 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. > > > > I agree with all aspects of this statement. I would *prefer* to keep > > it as a canary - with CI. > > > > Cheers. > > And interestingly, GCC49 appears to spot an issue introduced with commit > > commit a7fcab7aa3de338c02e61fd891610b1ec926e6c8 > Author: Hua Ma <hua...@intel.com> > Date: Mon Oct 11 11:43:12 2021 +0800 > > MdeModulePkg/Core/Dxe: Acquire a lock when iterating gHandleList > > where we may end up dereferencing a bogus 'Prot' pointer: > > MdeModulePkg/Core/Dxe/Hand/Handle.c:1198:24: > error: ‘Prot’ may be used uninitialized [-Werror=maybe-uninitialized] > 1198 | *Interface = Prot->Interface; > | ~~~~^~~~~~~~~~~ > MdeModulePkg/Core/Dxe/Hand/Handle.c:994:24: > note: ‘Prot’ was declared here > 994 | PROTOCOL_INTERFACE *Prot; > > So I am going to change my mind, and state that I do care about GCC > non-LTO builds, as we have been introducing bugs into our code that we > could have spotted if anyone had bothered to test with this toolchain > config. > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102398): https://edk2.groups.io/g/devel/message/102398 Mute This Topic: https://groups.io/mt/97919856/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
