From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from walk.intel-email.com (walk.intel-email.com [101.227.64.242]) by mx.groups.io with SMTP id smtpd.web11.90846.1680571922639078474 for ; Mon, 03 Apr 2023 18:32:03 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@byosoft.com.cn header.s=cloud-union header.b=TeeenLpf; spf=pass (domain: byosoft.com.cn, ip: 101.227.64.242, mailfrom: gaoliming@byosoft.com.cn) Received: from walk.intel-email.com (localhost [127.0.0.1]) by walk.intel-email.com (Postfix) with ESMTP id 6DE3BCD1F731 for ; Tue, 4 Apr 2023 09:31:59 +0800 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=byosoft.com.cn; s=cloud-union; t=1680571919; bh=IBwZyHlo6F3nG4w2raAF+inBAns8P8tpirXOlCOogNc=; h=From:To:Cc:References:In-Reply-To:Subject:Date; b=TeeenLpfGgBVMjd5496yXi2uclv7Aw52SwFdq3RAXpiVYTZMicUKpkirTWd2kCSCQ LQYy0w6r+ppnbboLnHusWUZ7mQJXQhc4h18T3SyRZCmjGb/+eVN16wvLx7a+vDbPpK 00OThtY8Gc35absMOcE6z1z7jeAfDXdQoSqGJ7vE= Received: from localhost (localhost [127.0.0.1]) by walk.intel-email.com (Postfix) with ESMTP id 69A4FCD1F72C for ; Tue, 4 Apr 2023 09:31:59 +0800 (CST) Received: from walk.intel-email.com (localhost [127.0.0.1]) by walk.intel-email.com (Postfix) with ESMTP id 405CBCD1F72B for ; Tue, 4 Apr 2023 09:31:59 +0800 (CST) Authentication-Results: walk.intel-email.com; none Received: from mail.byosoft.com.cn (mail.byosoft.com.cn [58.240.74.242]) by walk.intel-email.com (Postfix) with SMTP id CE58CCD1F77D for ; Tue, 4 Apr 2023 09:31:53 +0800 (CST) Received: from DESKTOPS6D0PVI ([58.246.60.130]) (envelope-sender ) by 192.168.6.13 with ESMTP for ; Tue, 04 Apr 2023 09:31:36 +0800 X-WM-Sender: gaoliming@byosoft.com.cn X-Originating-IP: 58.246.60.130 X-WM-AuthFlag: YES X-WM-AuthUser: gaoliming@byosoft.com.cn From: "gaoliming" To: "'Rebecca Cran'" , "'Pedro Falcato'" , Cc: "'Oliver Smith-Denny'" , "'Guomin Jiang'" , "'Xiaoyu Lu'" , "'Jian J Wang'" , "'Jiewen Yao'" , "'Ard Biesheuvel'" , "'Jordan Justen'" , "'Gerd Hoffmann'" , "'Bob Feng'" , "'Andrew Fish'" , "'Leif Lindholm'" , "'Michael D Kinney'" References: <20230328173111.759017-1-rebecca@bsdio.com> <02fb01d961dc$88d6acd0$9a840670$@byosoft.com.cn> <92a85636-3875-fd4d-06ff-dab9670370a5@bsdio.com> In-Reply-To: <92a85636-3875-fd4d-06ff-dab9670370a5@bsdio.com> Subject: =?UTF-8?B?5Zue5aSNOiDlm57lpI06IFtlZGsyLWRldmVsXSBbUEFUQ0ggdjIgMDAvMTNdIEJhc2VUb29scyxDcnlwdG9Qa2csTWRlUGtnLE92bWZQa2c6IERlbGV0ZSBDTEFORzM1LENMQU5HMzgsR0NDNDgsR0NDNDksIHJlbmFtZSBHQ0M1IHRvIEdDQywgdXBkYXRlIENMQU5HRFdBUkYsIGRlbGV0ZSBWUyAyMDA4LTIwMTMsIEVCQw==?= Date: Tue, 4 Apr 2023 09:31:37 +0800 Message-ID: <000201d96695$331dede0$9959c9a0$@byosoft.com.cn> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHBHvdh0M2RFPCHt4H2Dg8m0GbAEgIuvTblAiIFX20CKawdBQGy5vzOrwl/22A= Sender: "gaoliming" Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Language: zh-cn Rebecca: There are more discussion on GCC49 tool chain. So, I think it is the = safe way to keep GCC49 and GCC5 now. We can make the changes for other = tool chains first.=20 Thanks Liming > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: Rebecca Cran > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2023=E5=B9=B44=E6=9C=883=E6=97=A5 5:51 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Pedro Falcato ; = devel@edk2.groups.io > =E6=8A=84=E9=80=81: gaoliming ; Oliver = Smith-Denny > ; Guomin Jiang ; Xiaoyu > Lu ; Jian J Wang ; Jiewen = Yao > ; Ard Biesheuvel ; > Jordan Justen ; Gerd Hoffmann > ; Bob Feng ; Andrew Fish > ; Leif Lindholm ; Michael = D > Kinney > =E4=B8=BB=E9=A2=98: Re: =E5=9B=9E=E5=A4=8D: [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 >=20 > On 4/2/23 12:38 PM, Pedro Falcato wrote: > > As expressed off-list on UEFI talkbox, I like GCCNOLTO, but I would > > rather keep GCC5 as GCC5, for the next future iteration of "lets = bump > > a new toolchain because we need feature X". >=20 > Given we've gone from GCC 5 through 12 with no new toolchains, I'd > prefer to just have GCC. >=20 > > This is unsurprising, plenty of NOLTO build breakage. Since no one > > seems to use this, could we think about axing this or? > > > > Just seems silly to have an extra toolchain (with extra cognitive > > overhead for anyone looking at tools_def) for s/-flto//g >=20 > Since Liming wants to keep it, let's make all the other changes > (deleting VS 2008-2013, CLANG35, CLANG38 etc.) and keep GCCNOLTO and > GCC > for now. If nobody fixes the problems with GCCNOLTO, maybe we can > revisit dropping it in a few months? >=20 >=20 > -- >=20 > Rebecca Cran