On Mon, 3 Apr 2023 at 15:27, Kinney, Michael D <michael.d.kin...@intel.com> wrote: > > Are the same issue(s) found with GCC5 with -b NOOPT? >
None of these are found with NOOPT. Without the optimizer, GCC doesn't perform the analysis that is needed to figure out which variables are live (and valid) at which time, so it is not able to emit these diagnostics either. Note that the LTO compiler is not necessarily wrong here: it can generally see through all the function calls in a function, and so perhaps the state that the non-LTO compiler warns about is not actually reachable in the particular combination of components and libraries. However, relying on the LTO optimizer for this is fragile, and I'd much prefer having robust code that has additional checks for such states. By the same token, the LTO compiler will get rid of those if they are redundant and not needed for the program's correctness. > > > -----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 (#102399): https://edk2.groups.io/g/devel/message/102399 Mute This Topic: https://groups.io/mt/97919856/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
