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.web10.70567.1680529410299351295 for ; Mon, 03 Apr 2023 06:43:30 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=M1AtBl0Q; 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 59F54B81AC6 for ; Mon, 3 Apr 2023 13:43:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 28C51C433A0 for ; Mon, 3 Apr 2023 13:43:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1680529407; bh=UVNMQdOv/lK6CPHMOvr/oCX/WW4LKl5awZ5efLPnKfo=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=M1AtBl0Q0NiLi5KseWJZRued2/MbhIfe5EBqygHnIoDr7GXC4hSOWa4EaAK4+tXBy EClUagsrrvCL+qvGmVxMvUVoRrdTzPXDWQInsXv3rsqdrTwgoxUs7nU0kIWQj7vrnQ jwkSXWgHi+9jmSnk+MBzBmPG3PQkU9Ba44W11LXhOKyohEd3dvOngyMzf5F0a1a+tO KWoDp2lHWLsa0WH+L0WXHiOt9GZfwlMwNdMlrlHHhjehlUZgTgq2GFNOIK+8bj1PO8 r8WrSMsIjkUkk99cYoVNMxZz8SALkPnfmLfNlY06Ec5p7Ja9x0SRNr0aZn14nTl4H6 V1VPHnAcnvDRw== Received: by mail-lj1-f171.google.com with SMTP id o20so27464688ljp.3 for ; Mon, 03 Apr 2023 06:43:27 -0700 (PDT) X-Gm-Message-State: AAQBX9cpp4GX0FJzKHZJXSB7IhM9EKqqh+UWk2BB9Fv3j6qknhOta5eO +pB8ulfeJ3RziMW1oB2kjCtFo3HuqIhOg+xeOuc= X-Google-Smtp-Source: AKy350bcQXiWYbM6Y9ELt/8N5mnQTtNrHuUdkxFKf2qlHfcFv8oKd9RHBvz3tbcf+QWeEQ6TnxapuoPYaV7NbpC97lc= X-Received: by 2002:a2e:9d4d:0:b0:298:b375:acfc with SMTP id y13-20020a2e9d4d000000b00298b375acfcmr11022331ljj.2.1680529405190; Mon, 03 Apr 2023 06:43:25 -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 15:43:13 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: =?UTF-8?B?UmU6IOWbnuWkjTogW2VkazItZGV2ZWxdIFtQQVRDSCB2MiAwMC8xM10gQmFzZVRvb2xzLENyeXB0b1BrZyxNZGVQa2csT3ZtZlBrZzogRGVsZXRlIENMQU5HMzUsQ0xBTkczOCxHQ0M0OCxHQ0M0OSwgcmVuYW1lIEdDQzUgdG8gR0NDLCB1cGRhdGUgQ0xBTkdEV0FSRiwgZGVsZXRlIFZTIDIwMDgtMjAxMywgRUJD?= To: "Kinney, Michael D" Cc: "devel@edk2.groups.io" , "quic_llindhol@quicinc.com" , Gerd Hoffmann , "rebecca@bsdio.com" , Pedro Falcato , "Gao, Liming" , Oliver Smith-Denny , "Jiang, Guomin" , "Lu, Xiaoyu1" , "Wang, Jian J" , "Yao, Jiewen" , Ard Biesheuvel , "Justen, Jordan L" , "Feng, Bob C" , Andrew Fish Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 3 Apr 2023 at 15:27, Kinney, Michael D 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 On Behalf Of Ard Bies= heuvel > > Sent: Monday, April 3, 2023 6:05 AM > > To: devel@edk2.groups.io; quic_llindhol@quicinc.com > > Cc: Gerd Hoffmann ; rebecca@bsdio.com; Pedro Falcato= ; Gao, Liming > > ; Oliver Smith-Denny ; J= iang, Guomin ; Lu, Xiaoyu1 > > ; Wang, Jian J ; Yao, Jiew= en ; Ard Biesheuvel > > ; Justen, Jordan L ; Feng, Bob C ; Andrew Fish > > ; Kinney, Michael D > > Subject: Re: =E5=9B=9E=E5=A4=8D: [edk2-devel] [PATCH v2 00/13] BaseTool= s,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 = 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: =E2=80=98XCr0=E2=80=99 may be used uninitialized [-Werror=3D= maybe-uninitialized] > > > > > > > > seems to be a valid concern. > > > > > > > > So the point I am making is that OVMF gets a lot of attention in th= e > > > > 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 n= ot > > > > 100% relevant. > > > > > > > > So I am leaning towards retaining GCC49 as GCCNOLTO, and getting so= me > > > > coverage for it in CI, as we occasionally get useful diagnostics ou= t > > > > of it. But I am not going to fight any battles over it - I rarely u= se > > > > 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 commi= t > > > > commit a7fcab7aa3de338c02e61fd891610b1ec926e6c8 > > Author: Hua Ma > > 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: =E2=80=98Prot=E2=80=99 may be used uninitialized [-Werror=3Dmayb= e-uninitialized] > > 1198 | *Interface =3D Prot->Interface; > > | ~~~~^~~~~~~~~~~ > > MdeModulePkg/Core/Dxe/Hand/Handle.c:994:24: > > note: =E2=80=98Prot=E2=80=99 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. > > > > > >=20 > > >