From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id C701F21A16ECF for ; Tue, 20 Jun 2017 12:50:58 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id m47so19240194iti.1 for ; Tue, 20 Jun 2017 12:52:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=J8/qLb9ZS1BU1nYLXXxQDt5OGl9ZJVPjOr1SewKRw7I=; b=bmzrbRp3oQ0Nji0DSuqxChnf74G5XaoXLLx3A5O0XvkhFWrweipOZ9lqY/Fj7pLIO2 H3YDIA480wyu2NwhTkXmrKrJBk6+WdBQgxrPUwBEpPiipWtChVoaaeKKoyHC5PfTNRpy euQe2MghY57VsjpfnpusAbEaAsYYwzJiOUosw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=J8/qLb9ZS1BU1nYLXXxQDt5OGl9ZJVPjOr1SewKRw7I=; b=KFbSoaGXH6vGu4lmts9OeyDKF7y4/GF+g/C6xu7fPZegSF7rd2R/8wBzdKnTEFwoRt 0jyvR8gONo9BXNTYtSkAexfeMjr3ut8PI3DXEaPAmGCoFcmUv2gES+ufTFlZz7ABi1EO ciImm19QqPhNZgVGO2ZCaM5FOa8ZIks0k9PjIF0dq+NuiYMAVQ4oURpUXj9b5V4bE7N8 6RAzlDDgriHkT7vPhcrEmBZaLNYK7o6zzumxtZSGa92VfDbD4EzNsWg9CFjedcs6jqZs pDbn9FUhP7RGnBprpG96v4hz+JWNu8NvVrvPmKt+jqIi/SCcrxeVGQpLuqWajBHGvscy etZA== X-Gm-Message-State: AKS2vOwtOAtoIve4Fe6ZCelvfS7Ly6s4oFx9HIZ9YLnJ7QwIftVWMg2q +UgwbtlGHAt0Yztph99t/uh6Pd+fp2VZ X-Received: by 10.36.9.144 with SMTP id 138mr5384368itm.98.1497988341114; Tue, 20 Jun 2017 12:52:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.76 with HTTP; Tue, 20 Jun 2017 12:52:20 -0700 (PDT) In-Reply-To: References: <20170620110008.24413-1-leif.lindholm@linaro.org> <20170620120046.GZ26676@bivouac.eciton.net> From: Ard Biesheuvel Date: Tue, 20 Jun 2017 21:52:20 +0200 Message-ID: To: Laszlo Ersek Cc: Leif Lindholm , "edk2-devel@lists.01.org" , Ryan Harkin Subject: Re: [PATCH] ArmPlatformPkg: eliminate Juno gcc build warning 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: Tue, 20 Jun 2017 19:50:59 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 20 June 2017 at 17:44, Laszlo Ersek wrote: > On 06/20/17 14:00, Leif Lindholm wrote: >> On Tue, Jun 20, 2017 at 01:28:38PM +0200, Ard Biesheuvel wrote: >>> (+ Laszlo) >>> >>> On 20 June 2017 at 13:00, Leif Lindholm wrot= e: >>>> When building without LTO, gcc incorrectly resolves the hazards for >>>> 'PciRegBase=E2=80=99 when inlining, leading to "may be used uninitiali= zed" >>>> warnings (and hence build failure with -Werror). >>>> Eliminate this warning by explicitly initializing the variable to 0. >>>> >>>> Contributed-under: TianoCore Contribution Agreement 1.0 >>>> Signed-off-by: Leif Lindholm >>> >>> Reviewed-by: Ard Biesheuvel >> >> Thanks! >> >>>> --- >>>> >>>> For those who have heard me mentioning this before but arguing against >>>> upstreaming this patch: I only just tweaked that this warning doesn't >>>> go away with more recent toolchains, but simply when switching to GCC5 >>>> build profile, and hence LTO. Build failure still reproducible with >>>> gcc 6.3.1 and GCC49. >>> >>> /me annoyed >> >> +1 >> >>> We keep hitting this with GCC, and I profoundly dislike having to add >>> redundant initialization sequences. Is there any other solution >>> possible, e.g., disable this warning for certain builds? >> >> I would really like to not disable it. >> When it gets it right, that's usually a pretty horrific bug caught. >> And if we switch to LTO as the norm, I guess these will become less >> noticeable over time. >> But it does bug me too. > > Perhaps we should introduce two macros to "MdePkg/Include/Base.h", > > #define UNUSED_POINTER NULL > #define UNUSED_INTEGER 0 > > These could be used to suppress such warnings, without the risk of > misleading programmers (as to the real necessity of the variable > assignment at hand). > Or perhaps #ifdef __GNUC__ #define USED(var) var =3D (typeof(var))0 #else #define USED(var) #endif