From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 0810E7803E1 for ; Mon, 11 Dec 2023 17:26:55 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=q3Jl1GRSDFc4hGQovGVxUCnTbwjXTZPpXqnePwVZjIw=; c=relaxed/simple; d=groups.io; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:To:Cc:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type; s=20140610; t=1702315614; v=1; b=XHOXXXYqcvZuK/TiFyU5eGSHrWMjj4k6HdtHaZp3Fg98/NgSphwxLbQ6rNDVHfw88ih4e7+R Y4HzOKhCdI3UXnR1AjpS6uXARtRZ0QMi7SicrL1Re6UHoPtmia6RQpbUAIfcL4Louy1/v3huaqo ZZkM3pa2h6Np9eIl0dlD3WQ0= X-Received: by 127.0.0.2 with SMTP id 5txlYY7687511xi9QLMMWU6l; Mon, 11 Dec 2023 09:26:54 -0800 X-Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) by mx.groups.io with SMTP id smtpd.web10.1069.1702315613542848184 for ; Mon, 11 Dec 2023 09:26:53 -0800 X-Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-40c19f5f822so26582335e9.1 for ; Mon, 11 Dec 2023 09:26:53 -0800 (PST) X-Gm-Message-State: 1nxhId7aF2grxUAbnqsMzZjgx7686176AA= X-Google-Smtp-Source: AGHT+IGhTZDDutFKqn12mOdP/o2xFP825LanizQagciQ92CsB8Q+41Nw96LDRZCrxbEmAfCL5qn2+V9+BFlv2zYcxBY= X-Received: by 2002:a05:600c:b50:b0:40b:5e26:237f with SMTP id k16-20020a05600c0b5000b0040b5e26237fmr2191341wmr.48.1702315611652; Mon, 11 Dec 2023 09:26:51 -0800 (PST) MIME-Version: 1.0 References: <20231210101859.19198-1-mjsbeaton@gmail.com> <9b333ba1-7ce6-5be7-6482-3aadef7f1973@redhat.com> <12387048-80bf-87db-c15e-55583678863f@redhat.com> In-Reply-To: <12387048-80bf-87db-c15e-55583678863f@redhat.com> From: "Mike Beaton" Date: Mon, 11 Dec 2023 17:26:40 +0000 Message-ID: Subject: Re: [edk2-devel] [PATCH] BaseTools/tools_def: Disable unneeded-internal-declaration warning in CLANGPDB To: Laszlo Ersek Cc: devel@edk2.groups.io, Ard Biesheuvel , Ard Biesheuvel Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,mjsbeaton@gmail.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: Content-Type: text/plain; charset="UTF-8" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=XHOXXXYq; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io > > I believe this would be logically wrong, as the other versions still > > wouldn't compile if you changed the relevant debug Pcds. (Which are > > logically independent of the compile and link options - e.g. what if for > > some reason you wanted to single step with the Debug Pcds set to > > disabled, in a NOOPT build?) > > I don't think that use case exists in practice. > > Anyway, my suggestion is based on prior art: I *think* we ask gcc to > whine about unused local variables in RELEASE builds only, too. See > commits 20d00edf21d2 ("BaseTools/GCC: set -Wno-unused-but-set-variables > only on RELEASE builds", 2016-03-25) and 8b6366f87584 ("BaseTools/GCC: > set -Wno-unused-const-variable on RELEASE builds", 2017-09-08). > > ... TBH I don't understand the current state of > "-Wno-unused-but-set-variables" and "-Wno-unused-const-variable" between > X64 and AARCH64, considering the DEBUG target. Today, > DEBUG_GCC5_AARCH64_CC_FLAGS disables these warnings, but > DEBUG_GCC5_X64_CC_FLAGS doesn't, even though *both* macros specify > -flto. Compare commit 06c8a34cc4bc ("BaseTool/tools_def GCC5: enable > optimization for ARM/AARCH64 DEBUG builds", 2017-12-08) -- I don't > understand why "-flto" had to be accompanied by > "-Wno-unused-but-set-variable -Wno-unused-const-variable" in that commit. > > In brief, IA32 and X64 prior art supports my suggestion to shut up the > warning only for RELEASE (for CLANGPDB too), but ARM/AARCH64 prior art > contradicts that proposal. IOW, prior art is inconsistent per se... I > don't understand. > > Laszlo Hunting around further, it is not the Pcds which are causing this to be optimised away, but the definition of MDEPKG_NDEBUG. A completely different approach, which allows clang to spot that the usage has been 'optimised away' and so to not complain (and therefore allows us to re-enable the warning in CLANGDWARF as well), is the following: --- a/MdePkg/Include/Library/DebugLib.h +++ b/MdePkg/Include/Library/DebugLib.h @@ -426,7 +426,10 @@ UnitTestDebugAssert ( } \ } while (FALSE) #else -#define DEBUG(Expression) +#define DEBUG(Expression) \ + if (FALSE) { \ + _DEBUG (Expression); \ + } #endif /** -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#112323): https://edk2.groups.io/g/devel/message/112323 Mute This Topic: https://groups.io/mt/103087794/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=-