From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) by mx.groups.io with SMTP id smtpd.web11.22013.1680089323306335636 for ; Wed, 29 Mar 2023 04:28:43 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=Aks2sJFQ; spf=permerror, err=parse error for token &{10 18 %{ir}.%{v}.%{d}.spf.has.pphosted.com}: invalid domain name (domain: quicinc.com, ip: 205.220.168.131, mailfrom: quic_llindhol@quicinc.com) Received: from pps.filterd (m0279867.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 32TB52IS020639; Wed, 29 Mar 2023 11:28:32 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=qcppdkim1; bh=NbmQgdokD2HfLq83763E88w3IWz3gYCL/kE0CxDj8qQ=; b=Aks2sJFQLxYFn1J+W3FW8OlciK7DVT+gQurCLHhJmWHbJjNtuUclmNi5nm6DYreM8bpd QrcjV2WKxNWq6EItp4gGQqXVJK1c2vnYhBexePCgpK02xkmy4ZyDXv+89OK1Er5itCo0 /txKA9qayqLqD6cjOKd6o8JE7mNYCL+EZOc0QzNXMzBMvL554nNl2coU/Z/BTEBZSCXT wVDn+WMdHV//qKanod/RuIu9MhZv28gollChhIX8AvlwnEgQYmPHpEFYbSDEva0eQEyc lnutQOU1DEssL6c9LsLDMXa8VMl/0JsFM4qKG/GkZNh60gWJjQjgctg54PNdzNN1uhZU mg== Received: from nasanppmta02.qualcomm.com (i-global254.qualcomm.com [199.106.103.254]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3pmb8h18pd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 Mar 2023 11:28:32 +0000 Received: from nasanex01c.na.qualcomm.com (nasanex01c.na.qualcomm.com [10.45.79.139]) by NASANPPMTA02.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 32TBSV9O012955 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 Mar 2023 11:28:31 GMT Received: from qc-i7.hemma.eciton.net (10.80.80.8) by nasanex01c.na.qualcomm.com (10.45.79.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.42; Wed, 29 Mar 2023 04:28:27 -0700 Date: Wed, 29 Mar 2023 12:28:24 +0100 From: "Leif Lindholm" To: Ard Biesheuvel CC: , , , Oliver Smith-Denny , Guomin Jiang , Xiaoyu Lu , Jian J Wang , Jiewen Yao , Ard Biesheuvel , Jordan Justen , Gerd Hoffmann , Bob Feng , Andrew Fish , Michael D Kinney 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 Message-ID: References: <20230328173111.759017-1-rebecca@bsdio.com> <02fb01d961dc$88d6acd0$9a840670$@byosoft.com.cn> MIME-Version: 1.0 In-Reply-To: X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01a.na.qualcomm.com (10.52.223.231) To nasanex01c.na.qualcomm.com (10.45.79.139) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-ORIG-GUID: pE0EwLJ9QfU80bUWFQsr53nbvx2adsor X-Proofpoint-GUID: pE0EwLJ9QfU80bUWFQsr53nbvx2adsor X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22 definitions=2023-03-29_05,2023-03-28_02,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 mlxlogscore=999 malwarescore=0 priorityscore=1501 impostorscore=0 spamscore=0 phishscore=0 lowpriorityscore=0 adultscore=0 bulkscore=0 suspectscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2303200000 definitions=main-2303290095 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline On Wed, Mar 29, 2023 at 09:39:56 +0200, Ard Biesheuvel wrote: > > > - Remove GCC48 and GCC49. > > > > GCC49 is one GCC tool chain without LTO enable option. GCC5 is another GCC tool chain with LTO enable option. > > > > They have the different usage. I suggest to keep GCC49 and GCC5 both, and also keep their name as is. > > > > Could we perhaps do > > GCC49 -> GCC > GCC5 -> GCCLTO Might I suggest the inverse? GCC49 -> GCCNOLTO GCC5 -> GCC I feel disabling LTO should be seen as the nonstandard approach. Regardless, we (including me) *should* have changed those names as soon as we realised we didn't need a GCC51, and the misleading naming still frequently causes confusion. So I don't think keeping the current names should be considered an option. > ? > > As with CLANG35/38, the GCCx names have become rather obsolete, so I'd > prefer to have a set of more generic names, and a sliding window of > supported versions that can be documented in tools_def.template (and > updated at times) Agreed. And *if* we find a need in the future to add a new archived range, we can add that then. / Leif