From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id 80DE8460D5;
Tue, 21 Jan 2025 16:01:09 +0100 (CET)
Received: from mails.dpdk.org (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 23F7240280;
Tue, 21 Jan 2025 16:01:09 +0100 (CET)
Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com
[209.85.214.170])
by mails.dpdk.org (Postfix) with ESMTP id 39CB44021F
for <dev@dpdk.org>; Tue, 21 Jan 2025 16:01:07 +0100 (CET)
Received: by mail-pl1-f170.google.com with SMTP id
d9443c01a7336-21644aca3a0so128470885ad.3
for <dev@dpdk.org>; Tue, 21 Jan 2025 07:01:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1737471666;
x=1738076466; darn=dpdk.org;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:subject:cc:to:from:date:from:to:cc:subject:date
:message-id:reply-to;
bh=5rQYH14MfLfzrlGFoVekEQ8Ie0N2w1T8OG2cIshi5IE=;
b=P33xh50zBADSHc2t9iAkgfBLWzHAva/tTUB0n9yG2BFpBfaYMgFNln6V0xltDdE08o
ObNrs5/FMjEDUe7OQsQCOAo9sjOBLrrshoSOUowweXG4zhEnvMdBitO7Cw8OZO6zBApS
V4uS+VMZmXPx2PN/gAss/e9nPwEXn8p6xO4ZakIOdHVJi/Ys6PJPafgrbzFAZIuKIV1f
jHliygL56DGcnNcc4yUMWIitGQdxF5vCg14dqvUxFHlTzNz1G27U4i4vh2NphL72dzsA
Q+NLi7glXzcRbIJu06/FU7ToVAUauw1yzOXPjOZrjEOjbY5O+VLmGf88BQicRpqn/Kv4
0ZgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1737471666; x=1738076466;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=5rQYH14MfLfzrlGFoVekEQ8Ie0N2w1T8OG2cIshi5IE=;
b=VI8xm3RWC+hPoPUz0yQbVEZx/hrnlgJcEMf9gfaOAKDF/4p4c6W3z0eVoi0p1SoVAh
QFiOHphzoUM7ScQEGkCTXe4XJnxWcG92yhCxvrw7TlYHgoOdNX5OwsZ4YidShTn0GgO3
6/c8jHPx1iLQ0W3NZ0jO3gMYyhQSByQNun/FovroKn5x+KlEFU7LCHOlk9G0oB+3wz91
XEpX8KgnGf3e69QWyZd0FybAPzzMiQ2xpUcpaxlIurXHk8ilOzs7VHDlUrMUzhmFzKxf
bQx8UmBpMvhLDm+Mwg1/sZ+TULYyt4RShWpTyyNNFCSnf7BvhCiJXozyt22wrSkY9kTz
SkPA==
X-Forwarded-Encrypted: i=1;
AJvYcCVMYKnrRruHyDOelU31zgfDhNsnX0SDOwHAyYpEdtdIG9lgOAD0/K8tJgVg5ELO2mbHzzs=@dpdk.org
X-Gm-Message-State: AOJu0Yz6y2mv5b6kXih0CessAi+yQpnTcBce8c2zMU7I/0pBgRPC0dwr
yaUX+RGHPjxpQBndwNkzb5Cg7Q/DFqzxPwahTF5elpGoPJHmhHPzFxssr5Ba4Gw=
X-Gm-Gg: ASbGncvNF0Tn06AGb/aBidv5uh3HFq7nnZBW/JapJqyqRwnxGnh6ycN/3+5w2POBgRE
Js4ylaJXl1RItZgMpmA4xltKlYXqLX9n15pHrf0zAhMm3DgrxwjanBdHQNTm1HStPpoahTUzyam
5FxKG/LM73MaEmSBbvevVygt7BOvkLjCrDDV5e9Ec/tl9JDBUj85aRS2QiASCN8veOVsPhroNkK
01CGc6MKcCt4nDV7XaozDVRBSWapfUAqiRXxvZtrSAj0mxkrYDT0D9qkeGX9cz/P0ke6Tb5ELuJ
yTrFfEJzSWvmtPb5KZzcE1hMw97f1jtHouC2TSWFwLgI5JA=
X-Google-Smtp-Source: AGHT+IHSWhXe2o6mh1zMBs3no/IXtSBMvwGVvir247gyk0M2p+qVs039A+B6Beq7CH0resN4FP70UQ==
X-Received: by 2002:a05:6a20:728d:b0:1db:eead:c588 with SMTP id
adf61e73a8af0-1eb215ec4b9mr28876784637.29.1737471665922;
Tue, 21 Jan 2025 07:01:05 -0800 (PST)
Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226])
by smtp.gmail.com with ESMTPSA id
41be03b00d2f7-a9bcdcf7c87sm7646512a12.43.2025.01.21.07.01.05
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Tue, 21 Jan 2025 07:01:05 -0800 (PST)
Date: Tue, 21 Jan 2025 07:01:03 -0800
From: Stephen Hemminger <stephen@networkplumber.org>
To: Andre Muezerie <andremue@linux.microsoft.com>
Cc: Morten =?UTF-8?B?QnLDuHJ1cA==?= <mb@smartsharesystems.com>,
dev@dpdk.org, bruce.richardson@intel.com
Subject: Re: [PATCH v15 1/3] eal: add diagnostics macros to make code portable
Message-ID: <20250121070103.00a17914@hermes.local>
In-Reply-To: <20250121142816.GA30780@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
References: <1735263196-2809-1-git-send-email-andremue@linux.microsoft.com>
<1737237314-9844-1-git-send-email-andremue@linux.microsoft.com>
<1737237314-9844-2-git-send-email-andremue@linux.microsoft.com>
<98CBD80474FA8B44BF855DF32C47DC35E9F9CC@smartserver.smartshare.dk>
<20250121142816.GA30780@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
On Tue, 21 Jan 2025 06:28:16 -0800
Andre Muezerie <andremue@linux.microsoft.com> wrote:
> On Tue, Jan 21, 2025 at 10:53:14AM +0100, Morten Br=C3=B8rup wrote:
> > > From: Andre Muezerie [mailto:andremue@linux.microsoft.com]
> > > Sent: Saturday, 18 January 2025 22.55
> > >=20
> > > It was a common pattern to have "GCC diagnostic ignored" pragmas
> > > sprinkled over the code and only activate these pragmas for certain
> > > compilers (gcc and clang). Clang supports GCC's pragma for
> > > compatibility with existing source code, so #pragma GCC diagnostic
> > > and #pragma clang diagnostic are synonyms for Clang
> > > (https://clang.llvm.org/docs/UsersManual.html).
> > >=20
> > > Now that effort is being made to make the code compatible with MSVC
> > > these expressions would become more complex. It makes sense to hide
> > > this complexity behind macros. This makes maintenance easier as these
> > > macros are defined in a single place. As a plus the code becomes
> > > more readable as well.
> > >=20
> > > Signed-off-by: Andre Muezerie <andremue@linux.microsoft.com>
> > > ---
> > > lib/eal/include/rte_common.h | 46 ++++++++++++++++++++++++++++++++++=
++
> > > 1 file changed, 46 insertions(+)
> > >=20
> > > diff --git a/lib/eal/include/rte_common.h
> > > b/lib/eal/include/rte_common.h
> > > index 40592f71b1..4b87a0a352 100644
> > > --- a/lib/eal/include/rte_common.h
> > > +++ b/lib/eal/include/rte_common.h
> > > @@ -156,6 +156,52 @@ typedef uint16_t unaligned_uint16_t;
> > > #define RTE_DEPRECATED(x)
> > > #endif
> > >=20
> > > +/**
> > > + * Macros to cause the compiler to remember the state of the diagnos=
tics as of
> > > + * each push, and restore to that point at each pop.
> > > + */
> > > +#if !defined(__INTEL_COMPILER) && !defined(RTE_TOOLCHAIN_MSVC)
> > > +#define __rte_diagnostic_push _Pragma("GCC diagnostic push")
> > > +#define __rte_diagnostic_pop _Pragma("GCC diagnostic pop")
> > > +#else
> > > +#define __rte_diagnostic_push
> > > +#define __rte_diagnostic_pop
> > > +#endif
> > > +
> > > +/**
> > > + * Macro to disable compiler warnings about removing a type
> > > + * qualifier from the target type.
> > > + */
> > > +#if !defined(__INTEL_COMPILER) && !defined(RTE_TOOLCHAIN_MSVC)
> > > +#define __rte_diagnostic_ignored_wcast_qual \
> > > + _Pragma("GCC diagnostic ignored \"-Wcast-qual\"")
> > > +#else
> > > +#define __rte_diagnostic_ignored_wcast_qual
> > > +#endif
> > > +
> > > +/**
> > > + * Workaround to discard qualifiers (such as const, volatile, restri=
ct) from a pointer,
> > > + * without the compiler emitting a warning.
> > > + */
> > > +#define RTE_PTR_UNQUAL(X) ((void *)(uintptr_t)(X)) =20
> >=20
> > It seems the C23 typeof_unqual and the built-in pre-C23 __typeof_unqual=
__ couldn't be used.
> > Was it a generic issue, or only when operating on (the return value of)=
functions? =20
>=20
> I experimented with C23 typeof_unqual. It indeed works on gcc, clang and =
MSVC, but there are some details:
>=20
> a) With gcc the project needs to be compiled with -std=3Dc2x. Many other =
warnings show up, unrelated to the scope of this patchset. Some look suspic=
ious and should be looked at. An error also showed up, for which I sent out=
a small patch.
>=20
> b) When using typeof_unqual and passing "-Wcast-qual" to the compiler, a =
warning about the qualifier being dropped is emitted. The project currently=
uses "-Wcast-qual". Perhaps it shouldn't?
>=20
> Due to (a) I decided to not use typeof_unqual for now, but it would be tr=
ivial to change the macro to do so in the future.
Be careful, C23 changes some things like default initialization of padding =
bits.
Might break other stuff.