From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Permerror (SPF Permanent Error: More than 10 MX records returned) identity=mailfrom; client-ip=134.134.136.126; helo=mga18.intel.com; envelope-from=liming.gao@intel.com; receiver=edk2-devel@lists.01.org Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id BCD932214E338 for ; Mon, 11 Dec 2017 06:17:07 -0800 (PST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Dec 2017 06:21:45 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,391,1508828400"; d="scan'208";a="10923128" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by FMSMGA003.fm.intel.com with ESMTP; 11 Dec 2017 06:21:44 -0800 Received: from fmsmsx116.amr.corp.intel.com (10.18.116.20) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 11 Dec 2017 06:21:44 -0800 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by fmsmsx116.amr.corp.intel.com (10.18.116.20) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 11 Dec 2017 06:21:44 -0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.152]) by shsmsx102.ccr.corp.intel.com ([169.254.2.175]) with mapi id 14.03.0319.002; Mon, 11 Dec 2017 22:21:42 +0800 From: "Gao, Liming" To: Zenith432 , "edk2-devel@lists.01.org" Thread-Topic: [edk2] [PATCH 4/4] BaseTools: resolve initialization order errors in VfrFormPkg.h Thread-Index: AQHTcPxXLC5iLYc3mUGY2brabaCBKqM8efjQ//++V4CAAftZgA== Date: Mon, 11 Dec 2017 14:21:42 +0000 Message-ID: <4A89E2EF3DFEDB4C8BFDE51014F606A14E18FDC2@SHSMSX104.ccr.corp.intel.com> References: <1263998052.1770898.1512830709571.ref@mail.yahoo.com> <1263998052.1770898.1512830709571@mail.yahoo.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E18E283@SHSMSX104.ccr.corp.intel.com> <227fb275-6c49-48e9-f5b3-a00c7fcac909@users.sourceforge.net> In-Reply-To: <227fb275-6c49-48e9-f5b3-a00c7fcac909@users.sourceforge.net> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: Re: [PATCH 4/4] BaseTools: resolve initialization order errors in VfrFormPkg.h X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 14:17:07 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For VfrCompiler change, we will help verify VS tool chain. I think it is a = good enhancement.=20 For UefiLib.h issue, I agree this is an issue. For short term, we disable t= his warning. For long term, I expect to find one compatible solution or the= well discussed solution to reduce its impact. So, I ask the question on GC= C and VS compiler behavior for BOOLEAN data type in function. Thanks Liming > -----Original Message----- > From: Zenith432 [mailto:zenith432@users.sourceforge.net] > Sent: Monday, December 11, 2017 12:02 AM > To: Gao, Liming ; edk2-devel@lists.01.org > Subject: Re: [edk2] [PATCH 4/4] BaseTools: resolve initialization order e= rrors in VfrFormPkg.h >=20 > On 10/12/2017 03:52 PM, Gao, Liming wrote: > > I think these patches resolves CLANG build issues in BaseTools. Do you = verify them with GCC or VS tool chain? > > > GCC 7.2 does not give any of the warnings generated by clang while compil= ing BaseTools. > After applying the 4 BaseTools patches, it still does not give any warnin= gs (or errors). > I don't have VS toolchain to try on. >=20 > For VfrFormPkg.h, there is simpler solution to surround all the offending= code in >=20 > #pragma clang diagnostic push > #pragma clang diagnostic ignored "-Wuninitialized" > > #pragma clang diagnostic pop >=20 > I sent you this option last week, you said you prefer to resolve the reas= on for the "-Wuninitialized". > The reason is the attempt in 100 or so derived classes to force an initia= lization order different than C++. It's > undefined behavior. Any resolution for the undefined behavior involves c= hanging those 100 derived classes, so a massive > code change. The existing code works, it's just an attempt to get around= standard C++ initialization order. Clang > wants to give pedantic warnings, but can be silenced if the "undefined be= havioral" code is known to work. >=20 > The other 3 BaseTools patches are rather small. >=20 > Also, with the VA_START(Args, BOOLEAN) bug (bug 741), there is an option = of silencing clang locally around the offending > statement > #pragma clang diagnostic push > #pragma clang diagnostic ignored "-Wvarargs" > VA_START(Args, Iso639Language); > #pragma clang diagnostic pop >=20 > And then remove global silencing of this warning in tools_def.txt. That = way any other not yet considered warnings will > be caught in the future. >=20 > It's up to you how to go about it... big code changes, silencing warning= locally or silencing warning globally.