From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id A0E30A0526; Tue, 21 Jul 2020 09:09:28 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 805EB1C032; Tue, 21 Jul 2020 09:09:28 +0200 (CEST) Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by dpdk.org (Postfix) with ESMTP id 133FE1C010 for ; Tue, 21 Jul 2020 09:09:27 +0200 (CEST) Received: by mail-wr1-f68.google.com with SMTP id f18so20115367wrs.0 for ; Tue, 21 Jul 2020 00:09:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=gl+0WeuxvBifxJ07kWHCowe5jyj0k4J3sdPwJWjHdzs=; b=hpVmpOze+NXVH+HEL0Zh1XYA8WM1xTRbyE2EWVYJjw7i9UggL18tDD3JFZrmq43wVQ g12XWOOB2Eut37FvwTK63Zl0UQoIRkkMn5t/7CCdOVer4HwxHIC6J226kPshUzSwo2BB p2c0c2yYp+pj0X6nzrwCI9mruaBod9vUtfAbh7C9hgvu7lhdP7vkqzkYrgvGTScX2ToW 7KHG5w3PdLQfQR1jJ4qV3E6NTGhxftX+uOhKM8lIclULZ7z8jhLDppevqiUA0JBj3J2d HUwsa06xZClqvomAtB4XKrqPoaDHli4Fb/eoid+zzRMIr/ZefRs98yiJ1FENyuJXhF/m 1/kA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=gl+0WeuxvBifxJ07kWHCowe5jyj0k4J3sdPwJWjHdzs=; b=LqStZPVH99cVA/kpw2S9go5aiomNi9ckN2DBUWlV4FAmYPlsBTZWPP3z+sxtJDlNuJ JOtgd2u4mdnmNPhQq8zMkgbrJZMjoUhjg3Is9LIRjvluvoYDAlUQCV1qmMUNsmr6I07w kQajohISH3lGrggTunXx0KOjkd8KJr4DecjYX0zDOE+mDtchyhOE2AyPMiAlEcOrbBJJ IhIzTQwicXzywmnXUVcPX1nsC+g41aq5TdPev/qdTz5OSUPrk8EH9eqFpzzlbFAKUVSW Z75boF+J46omrfX25PgNOQV2dV9GzeDVzNhy7tsvcyULpeSn1SJO8dh5pNLDiy6Ri/+f /+Jw== X-Gm-Message-State: AOAM5335y+zNS35guvXAvynjphSRXGY9ZTf7k1gSCfAhjxe6O//fhOk9 ccGBVoDFRINOI8AE3muUynayPw== X-Google-Smtp-Source: ABdhPJwOr4Vd3QbC8RYX6zTB2+PftAMTUi5m21mRqAUwVQAe5kOl0wHkGzsEHVhTBqIMb1VJUybNLw== X-Received: by 2002:adf:f842:: with SMTP id d2mr27433831wrq.55.1595315366783; Tue, 21 Jul 2020 00:09:26 -0700 (PDT) Received: from 6wind.com (2a01cb0c0005a600345636f7e65ed1a0.ipv6.abo.wanadoo.fr. [2a01:cb0c:5:a600:3456:36f7:e65e:d1a0]) by smtp.gmail.com with ESMTPSA id f12sm36351428wrj.48.2020.07.21.00.09.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Jul 2020 00:09:26 -0700 (PDT) Date: Tue, 21 Jul 2020 09:09:25 +0200 From: Olivier Matz To: Ferruh Yigit Cc: Raslan Darawsheh , dev@dpdk.org, stable@dpdk.org Message-ID: <20200721070925.GF5869@platinum> References: <1594901556-11826-1-git-send-email-rasland@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [dpdk-dev] [PATCH] net: fix compilation with pedantic enabled X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi, On Tue, Jul 21, 2020 at 01:05:57AM +0100, Ferruh Yigit wrote: > On 7/16/2020 1:12 PM, Raslan Darawsheh wrote: > > when trying to compile rte_mpls with pedantic enabled, > > it will complain about bit field defintion. > > error: type of bit-field 'bs' is a GCC extension [-Werror=pedantic] > > error: type of bit-field 'tc' is a GCC extension [-Werror=pedantic] > > error: type of bit-field 'tag_lsb' is a GCC extension [-Werror=pedantic] > ' > I tried to reproduce by adding to '-pedantic' to 'rte_net.c' (which uses > 'rte_mpls.h') but not able to get the warning. Is this happen with specific > version of the compiler? > > > > > This fixes the compilation error. > > > > Fixes: e480cf487a0d ("net: add MPLS header structure") > > Cc: olivier.matz@6wind.com > > Cc: stable@dpdk.org > > > > Signed-off-by: Raslan Darawsheh > > --- > > lib/librte_net/rte_mpls.h | 12 ++++++------ > > 1 file changed, 6 insertions(+), 6 deletions(-) > > > > diff --git a/lib/librte_net/rte_mpls.h b/lib/librte_net/rte_mpls.h > > index db91707..ecd1f64 100644 > > --- a/lib/librte_net/rte_mpls.h > > +++ b/lib/librte_net/rte_mpls.h > > @@ -24,13 +24,13 @@ extern "C" { > > struct rte_mpls_hdr { > > uint16_t tag_msb; /**< Label(msb). */ > > #if RTE_BYTE_ORDER == RTE_BIG_ENDIAN > > - uint8_t tag_lsb:4; /**< Label(lsb). */ > > - uint8_t tc:3; /**< Traffic class. */ > > - uint8_t bs:1; /**< Bottom of stack. */ > > + uint32_t tag_lsb:4; /**< Label(lsb). */ > > + uint32_t tc:3; /**< Traffic class. */ > > + uint32_t bs:1; /**< Bottom of stack. */ > > #else > > - uint8_t bs:1; /**< Bottom of stack. */ > > - uint8_t tc:3; /**< Traffic class. */ > > - uint8_t tag_lsb:4; /**< label(lsb) */ > > + uint32_t bs:1; /**< Bottom of stack. */ > > + uint32_t tc:3; /**< Traffic class. */ > > + uint32_t tag_lsb:4; /**< label(lsb) */ > > #endif > > uint8_t ttl; /**< Time to live. */ > > } __rte_packed; > > The struct size keeps same after change, do you know if this behavior is part of > standard and guaranteed? I have the same fear. Would it make sense to add __extension__ instead? We already do that for gre, for instance.