From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 5B9B221D492F6 for ; Thu, 14 Sep 2017 01:58:09 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9ED31C04B94B; Thu, 14 Sep 2017 09:01:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 9ED31C04B94B Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=lersek@redhat.com Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-83.rdu2.redhat.com [10.10.120.83]) by smtp.corp.redhat.com (Postfix) with ESMTP id 07165756C3; Thu, 14 Sep 2017 09:01:05 +0000 (UTC) To: "Zeng, Star" , Ard Biesheuvel Cc: "Ni, Ruiyu" , "Dong, Eric" , edk2-devel-01 , "Gao, Liming" References: <20170912222612.14451-1-lersek@redhat.com> <20170912222612.14451-3-lersek@redhat.com> <0C09AFA07DD0434D9E2A0C6AEB0483103B94098B@shsmsx102.ccr.corp.intel.com> <0C09AFA07DD0434D9E2A0C6AEB0483103B9409E7@shsmsx102.ccr.corp.intel.com> <23e789a8-59df-d67d-fa16-fc70aafb95d7@redhat.com> <0C09AFA07DD0434D9E2A0C6AEB0483103B94A227@SHSMSX151.ccr.corp.intel.com> <9b40bdd1-206d-54f8-b83a-b8c2eccae3f2@redhat.com> <0C09AFA07DD0434D9E2A0C6AEB0483103B956B56@SHSMSX151.ccr.corp.intel.com> From: Laszlo Ersek Message-ID: <77374b3b-f322-7d71-9119-eee76222aee4@redhat.com> Date: Thu, 14 Sep 2017 11:01:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <0C09AFA07DD0434D9E2A0C6AEB0483103B956B56@SHSMSX151.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Thu, 14 Sep 2017 09:01:07 +0000 (UTC) Subject: Re: [PATCH 2/2] MdeModulePkg/UdfDxe: suppress incorrect compiler warning in ReadFile() 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: Thu, 14 Sep 2017 08:58:09 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 09/14/17 10:50, Zeng, Star wrote: > Is there GCC compiler version fixed this kind of false alarm? > If yes, the lesser versions without fix are what I mean *OLD*. Unfortunately, I cannot answer your question, for two reasons: - First, I'm unsure what you mean by "lesser version". For example, if gcc-4.8.4 emits a warning incorrectly, but gcc-4.8.5 does not, then I agree we can require users to use gcc-4.8.5. Linux distributions consider this a "stable update" anyway, and will generally ship the version with the higher "patch level". (The version number comes together from ...) However, if the same difference is between gcc-4.7 and gcc-4.8, then the same requirement cannot be made. Distros will not upgrade gcc from one minor version to another in a stable release. - Second, even if I knew how exactly to interpret your question, I can't answer! The way the warnings change in gcc over time is totally impenetrable to the end-user. The data flow analysis is tied to the optimizer AFAICT, and unless you are a gcc developer yourself, the warning changes appear simply as chaos, from release to release. In practice, new releases will stop emitting invalid warnings that earlier releases used to, but the new release may also emit new incorrect warnings. (I.e., it might emit the *same kind* of warning, incorrectly, for a new kind of *context*.) Laszlo > -----Original Message----- > From: Laszlo Ersek [mailto:lersek@redhat.com] > Sent: Thursday, September 14, 2017 4:17 PM > To: Zeng, Star ; Ard Biesheuvel > Cc: Ni, Ruiyu ; Dong, Eric ; edk2-devel-01 ; Gao, Liming > Subject: Re: [edk2] [PATCH 2/2] MdeModulePkg/UdfDxe: suppress incorrect compiler warning in ReadFile() > > On 09/14/17 02:42, Zeng, Star wrote: >> Comparing adding workaround in code with suppressing it in *OLD* version GCCs, I prefer the latter personally. > > But, how old is old? > > The base compiler in RHEL-7 is gcc-4.8. That's what I use every day. > > The base compiler in Debian old-old-stable (still supported), is gcc-4.7 (for IA32 and X64). > > The base compiler in RHEL-6 (still supported) is gcc-4.4. Is that old? > > Thanks > Laszlo > >> -----Original Message----- >> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of >> Ard Biesheuvel >> Sent: Thursday, September 14, 2017 2:52 AM >> To: Laszlo Ersek >> Cc: Ni, Ruiyu ; Dong, Eric ; >> edk2-devel-01 ; Gao, Liming >> ; Zeng, Star >> Subject: Re: [edk2] [PATCH 2/2] MdeModulePkg/UdfDxe: suppress >> incorrect compiler warning in ReadFile() >> >> On 13 September 2017 at 11:49, Laszlo Ersek wrote: >>> On 09/13/17 08:43, Zeng, Star wrote: >>>> Beyond the Rb (I do not want to block this patch series), I am curious about one question. >>>> >>>> There may be more this kind of workarounds to fix the build failure. >>>> Is it possible to disable the warning (like below example for VS) for specific version of GCC for this kind of false alarm? >>>> >>>> >>>> ProcessorBind.h: >>>> #if defined(_MSC_EXTENSIONS) >>>> >>>> ... >>>> >>>> #if _MSC_VER == 1800 || _MSC_VER == 1900 >>>> >>>> // >>>> // Disable these warnings for VS2013. >>>> // >>>> >>>> // >>>> // This warning is for potentially uninitialized local variable, and >>>> it may cause false // positive issues in VS2013 and VS2015 build // >>>> #pragma warning ( disable : 4701 ) >>>> >>>> // >>>> // This warning is for potentially uninitialized local pointer >>>> variable, and it may cause // false positive issues in VS2013 and >>>> VS2015 build // #pragma warning ( disable : 4703 ) >>>> >>>> #endif >>>> >>>> #endif >>> >>> I think starting with gcc-4.6, gcc supports the "diagnostics" pragma, >>> which can be used to suppress warnings. >>> >>> Unfortunately, there's no pragma to suppress *only* the incorrect >>> warnings :) So if we set the pragma, we could lose even those >>> warnings that point out real bugs. >>> >> >> That applies to the VS case as well. But I think doing this for older GCCs is fine, most EDK2 developers use a newer version anyway, so we will not lose any coverage by doing so. >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel >> >