From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65])
by mx.groups.io with SMTP id smtpd.web11.21326.1598541915371823804
for <devel@edk2.groups.io>;
Thu, 27 Aug 2020 08:25:15 -0700
Authentication-Results: mx.groups.io;
dkim=pass header.i=@nuviainc-com.20150623.gappssmtp.com header.s=20150623 header.b=pIzQdv1i;
spf=pass (domain: nuviainc.com, ip: 209.85.128.65, mailfrom: leif@nuviainc.com)
Received: by mail-wm1-f65.google.com with SMTP id c19so3964390wmd.1
for <devel@edk2.groups.io>; Thu, 27 Aug 2020 08:25:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=nuviainc-com.20150623.gappssmtp.com; s=20150623;
h=date:from:to:cc:subject:message-id:references:mime-version
:content-disposition:in-reply-to:user-agent;
bh=FHOqHO1OzHHHVF8XAvlJRx5/GN2mo1J+A8DRFSBLss0=;
b=pIzQdv1iwkdUROO9fuN5RWrPA00uOLFDDOPNUFGe+E9SCUlz9vgR9dT3o+XcQgBnrw
CzdmLCGnf/A6G+xJuN+wOuXzltwO4d30tQU43w5KaHhp9/GQfrgRZ0llVhIEn8uCRXrb
jfNKPol57CYYeDkdd31EfcOEAqWJv218zWFqLKxhuzMnwJngXOXjRRglK8ekh3ECXJAJ
7D6+HPW9uXY8EXW8o/w4IfN2PWzd1gTiWCkGrkx1dMgzJ8WIzmxZmvbq4/RidyBRAE9k
ORV+wVw9vrt8Zmxy8sqTXEqq5tcngQqlsX4sliKcTutmlcErtxgkaMbG3oH1NzjeAh+0
R+TQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:date:from:to:cc:subject:message-id:references
:mime-version:content-disposition:in-reply-to:user-agent;
bh=FHOqHO1OzHHHVF8XAvlJRx5/GN2mo1J+A8DRFSBLss0=;
b=NWpHU7jNPfwKRIDVJtg8M/9d10dR510X/pps9sF1ncF83evnJTM4wagd2QMJl+DBjt
AIGmwJ0WMU1rQ57UoRHf2ZTrxpGjLG3heAB0B6M52vG5qulA81M53HaLz7co5Tu5ORtv
W95kLoVvl/F/U648E7INQRO2x1Ltgr5r8OBcJ8cRhNKYtgbAreuXeKgq4Vp+P0KDNAiy
ln/XZ1JhWqam8h01F3BZV7ACTqOmVNZGPqcjBDDKNz9o2gmMeUMuL3zjYHOZj6D/v24I
XTPf8jPDkNOcbmTzT7Mi3s7uZ8p6kiW6EdVUSgzWaGja3Z8JiKtDtqUo+T4CfYwAy9Z/
80gg==
X-Gm-Message-State: AOAM532EQ5RZIqaqMMWNwWwNx54Q48X9Y4I/er/i3IGIm9hMY4M1bVog
rDo2kGSxkfupy25NP5IjlvIbgw==
X-Google-Smtp-Source: ABdhPJzD6lUWeAq2A+f8BJTBSgjtNPCSx1jTT6Ss6d/8AGcm70VRb2hoyqZIYBqngmR77OvZoKM3Mw==
X-Received: by 2002:a05:600c:20a:: with SMTP id 10mr12497217wmi.160.1598541913788;
Thu, 27 Aug 2020 08:25:13 -0700 (PDT)
Return-Path: <leif@nuviainc.com>
Received: from vanye ([2001:470:1f09:12f0:b26e:bfff:fea9:f1b8])
by smtp.gmail.com with ESMTPSA id q8sm6460335wrx.79.2020.08.27.08.25.12
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Thu, 27 Aug 2020 08:25:13 -0700 (PDT)
Date: Thu, 27 Aug 2020 16:25:11 +0100
From: "Leif Lindholm" <leif@nuviainc.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: Pierre Gondois <Pierre.Gondois@arm.com>,
"devel@edk2.groups.io" <devel@edk2.groups.io>,
"bob.c.feng@intel.com" <bob.c.feng@intel.com>,
"liming.gao@intel.com" <liming.gao@intel.com>,
Tomas Pilar <Tomas.Pilar@arm.com>, nd <nd@arm.com>,
Ard Biesheuvel <Ard.Biesheuvel@arm.com>
Subject: Re: [edk2-devel] [PATCH V2 2/2] BaseTools: Factorize GCC flags
Message-ID: <20200827152511.GX1191@vanye>
References: <20200707083522.138944-1-pierre.gondois@arm.com>
<20200707083522.138944-3-pierre.gondois@arm.com>
<879fda8a-37bd-a902-6028-c879ed37fa28@redhat.com>
<22b94ad5-db03-7280-4032-6ebf8dfc1d49@redhat.com>
<DB7PR08MB311372A916B31C96DF828F6E8B550@DB7PR08MB3113.eurprd08.prod.outlook.com>
<518916e0-53cc-732b-cf1b-1e1b8d10a3b3@redhat.com>
MIME-Version: 1.0
In-Reply-To: <518916e0-53cc-732b-cf1b-1e1b8d10a3b3@redhat.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Thu, Aug 27, 2020 at 16:55:11 +0200, Laszlo Ersek wrote:
> On 08/27/20 10:32, Pierre Gondois wrote:
> > Hello Laszlo,
> > I thought Leif wanted to revert this modification. Should I apply
> your requested changes, or should this patch be reverted?
>
> The *other* patch in this series has indeed been reverted:
>
> - original commit: dbd546a32d5a ("BaseTools: Add gcc flag to warn on
> void* pointer arithmetic", 2020-07-21)
>
> - revert: 91e4bcb313f0 ("Revert "BaseTools: Add gcc flag to warn on
> void* pointer arithmetic"", 2020-07-24)
>
> I'm not sure what the intent was ultimately with this patch though.
> (I.e., keep it or revert it.) Personally I'm not calling for a revert;
> I'd just like the "-Os" duplication to be eliminated. Also it doesn't
> need to occur for this stable tag, just eventually.
>
> Leif, please comment!
I did propose reverting it. But I asked for Ard's feedback on the
reason for why we had the break in the flags-chain, in case he
remembered (and he was on holiday at the time).
Basically, I'm wondering whether we're better off changing this
behaviour or simply nuking GCC48.
Regards,
Leif
> Thanks!
> Laszlo
>
> >
> > Regards,
> > Pierre
> >
> > -----Original Message-----
> > From: Laszlo Ersek <lersek@redhat.com>
> > Sent: Wednesday, August 26, 2020 5:43 PM
> > To: Pierre Gondois <Pierre.Gondois@arm.com>
> > Cc: devel@edk2.groups.io; bob.c.feng@intel.com; liming.gao@intel.com; Tomas Pilar <Tomas.Pilar@arm.com>; nd <nd@arm.com>; Leif Lindholm (Nuvia address) <leif@nuviainc.com>; Ard Biesheuvel <Ard.Biesheuvel@arm.com>
> > Subject: Re: [edk2-devel] [PATCH V2 2/2] BaseTools: Factorize GCC flags
> >
> > On 07/22/20 13:03, Laszlo Ersek wrote:
> >> Hi Pierre,
> >>
> >> On 07/07/20 10:35, PierreGondois wrote:
> >>> From: Pierre Gondois <pierre.gondois@arm.com>
> >>>
> >>> GCC48_ALL_CC_FLAGS has no dependency on GCC_ALL_CC_FLAGS.
> >>> By definition, there should be such dependency.
> >>>
> >>> The outcomes of this patch is that GCC48_ALL_CC_FLAGS and other
> >>> dependent configurations will inherit from the additional "-Os" flag.
> >>> The "-Os" flag optimizes a build in size, not breaking any build. In
> >>> a gcc command line, the last optimization flag has precedence. This
> >>> means that this "-Os" flag will be overriden by a more specific
> >>> optimization configuration, provided that this more specific flag is
> >>> appended at the end of the CC_FLAGS.
> >>>
> >>> Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
> >>> Suggested-by: Tomas Pilar <Tomas.Pilar@arm.com>
> >>> ---
> >>>
> >>> The changes can be seen at:
> >>> https://github.com/PierreARM/edk2/commits/831_Add_gcc_flag_warning_v2
> >>>
> >>> Notes:
> >>> v2:
> >>> - Make GCC48_ALL_CC_FLAGS dependent on
> >>> GCC_ALL_CC_FLAGS. [Tomas]
> >>>
> >>> BaseTools/Conf/tools_def.template | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/BaseTools/Conf/tools_def.template
> >>> b/BaseTools/Conf/tools_def.template
> >>> index
> >>> 397b011ba38f97f81f314f8641ac8bb95d5a2197..a1fd27b1adba8769949b7d628d7
> >>> fbed49fe24267 100755
> >>> --- a/BaseTools/Conf/tools_def.template
> >>> +++ b/BaseTools/Conf/tools_def.template
> >>> @@ -1952,7 +1952,7 @@ DEFINE GCC_RISCV64_RC_FLAGS = -I binary -O elf64-littleriscv -B riscv
> >>> # GCC Build Flag for included header file list generation
> >>> DEFINE GCC_DEPS_FLAGS = -MMD -MF $@.deps
> >>>
> >>> -DEFINE GCC48_ALL_CC_FLAGS = -g -fshort-wchar -fno-builtin -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -ffunction-sections -fdata-sections -include AutoGen.h -fno-common -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
> >>> +DEFINE GCC48_ALL_CC_FLAGS = DEF(GCC_ALL_CC_FLAGS) -ffunction-sections -fdata-sections -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
> >>> DEFINE GCC48_IA32_X64_DLINK_COMMON = -nostdlib -Wl,-n,-q,--gc-sections -z common-page-size=0x20
> >>> DEFINE GCC48_IA32_CC_FLAGS = DEF(GCC48_ALL_CC_FLAGS) -m32 -march=i586 -malign-double -fno-stack-protector -D EFI32 -fno-asynchronous-unwind-tables -Wno-address
> >>> DEFINE GCC48_X64_CC_FLAGS = DEF(GCC48_ALL_CC_FLAGS) -m64 -fno-stack-protector "-DEFIAPI=__attribute__((ms_abi))" -maccumulate-outgoing-args -mno-red-zone -Wno-address -mcmodel=small -fpie -fno-asynchronous-unwind-tables -Wno-address
> >>>
> >>
> >> As the commit message states, this change makes GCC48_ALL_CC_FLAGS inherit "-Os".
> >>
> >> It is true that all the NOOPT_GCC flags override "-Os" with "-O0":
> >>
> >> NOOPT_GCC48_IA32_CC_FLAGS = DEF(GCC48_IA32_CC_FLAGS) -O0
> >> NOOPT_GCC48_X64_CC_FLAGS = DEF(GCC48_X64_CC_FLAGS) -O0
> >> NOOPT_GCC48_ARM_CC_FLAGS = DEF(GCC48_ARM_CC_FLAGS) -O0
> >> NOOPT_GCC48_AARCH64_CC_FLAGS = DEF(GCC48_AARCH64_CC_FLAGS) -O0
> >> NOOPT_GCC49_IA32_CC_FLAGS = DEF(GCC49_IA32_CC_FLAGS) -O0
> >> NOOPT_GCC49_X64_CC_FLAGS = DEF(GCC49_X64_CC_FLAGS) -O0
> >> NOOPT_GCC49_ARM_CC_FLAGS = DEF(GCC49_ARM_CC_FLAGS) -O0
> >> NOOPT_GCC49_AARCH64_CC_FLAGS = DEF(GCC49_AARCH64_CC_FLAGS) -O0
> >> NOOPT_GCC5_IA32_CC_FLAGS = DEF(GCC5_IA32_CC_FLAGS) -O0
> >> NOOPT_GCC5_X64_CC_FLAGS = DEF(GCC5_X64_CC_FLAGS) -O0
> >> NOOPT_GCC5_ARM_CC_FLAGS = DEF(GCC5_ARM_CC_FLAGS) -O0
> >> NOOPT_GCC5_AARCH64_CC_FLAGS = DEF(GCC5_AARCH64_CC_FLAGS) -O0
> >>
> >> However, *some* of the DEBUG and RELEASE flags now have two "-Os" flags:
> >>
> >> DEBUG_GCC48_IA32_CC_FLAGS = DEF(GCC48_IA32_CC_FLAGS) -Os
> >> RELEASE_GCC48_IA32_CC_FLAGS = DEF(GCC48_IA32_CC_FLAGS) -Os -Wno-unused-but-set-variable
> >> DEBUG_GCC48_X64_CC_FLAGS = DEF(GCC48_X64_CC_FLAGS) -Os
> >> RELEASE_GCC48_X64_CC_FLAGS = DEF(GCC48_X64_CC_FLAGS) -Os -Wno-unused-but-set-variable
> >> DEBUG_GCC49_IA32_CC_FLAGS = DEF(GCC49_IA32_CC_FLAGS) -Os
> >> RELEASE_GCC49_IA32_CC_FLAGS = DEF(GCC49_IA32_CC_FLAGS) -Os -Wno-unused-but-set-variable -Wno-unused-const-variable
> >> DEBUG_GCC49_X64_CC_FLAGS = DEF(GCC49_X64_CC_FLAGS) -Os
> >> RELEASE_GCC49_X64_CC_FLAGS = DEF(GCC49_X64_CC_FLAGS) -Os -Wno-unused-but-set-variable -Wno-unused-const-variable
> >> DEBUG_GCC5_IA32_CC_FLAGS = DEF(GCC5_IA32_CC_FLAGS) -flto -Os
> >> RELEASE_GCC5_IA32_CC_FLAGS = DEF(GCC5_IA32_CC_FLAGS) -flto -Os -Wno-unused-but-set-variable -Wno-unused-const-variable
> >> DEBUG_GCC5_X64_CC_FLAGS = DEF(GCC5_X64_CC_FLAGS) -flto -DUSING_LTO -Os
> >> RELEASE_GCC5_X64_CC_FLAGS = DEF(GCC5_X64_CC_FLAGS) -flto -DUSING_LTO -Os -Wno-unused-but-set-variable -Wno-unused-const-variable
> >>
> >> (The ARM and AARCH64 DEBUG/RELEASE GCC options don't seem to be
> >> affected, as they have relied on inherited -- not open-coded -- "-Os"
> >> options from much earlier. So now they do not suffer from this
> >> duplication.)
> >>
> >> The point of this patch was a kind of "normalization", so I think the work isn't complete until the duplication is undone, i.e., the explicit "-Os" flag is removed from the last twelve defines.
> >>
> >> Can you submit a follow-up patch please?
> >
> > I have not received an answer, and I'm not aware of a follow-up patch being on the list; so now I've filed:
> >
> > https://bugzilla.tianocore.org/show_bug.cgi?id=2928
> >
> > Thanks
> > Laszlo
> >
>