From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 3A1751B020 for ; Wed, 17 Jan 2018 23:52:30 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id E0CBD20BE9; Wed, 17 Jan 2018 17:52:29 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 17 Jan 2018 17:52:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=cMf/2HWmjKlU+N+c0nUYRKg9Ws i6traJ+uBEQ9L8N/U=; b=RZ4N8E515cyBL370LF0DnWWcmaGhAlp3Nmv4foaHNM W945ha4hO6ObFI4N1Ar6i/yfGatdZtjjurdGCGssO9yLq0Jop+u99rnJF51BtLs/ 2oiSxYv/aSi59dKRXM4I25YkEjhMtTTxKf3gjdmT3tT9KuMX1M8MvaB90WpM/Gf4 4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=cMf/2H WmjKlU+N+c0nUYRKg9Wsi6traJ+uBEQ9L8N/U=; b=FozeJ6un51ujdekB4MiZlp mw5A0j7uvoIZflEPejOXYXZfVWlKgKvqejtbn3E2nj8Zojjn+XOgbJx+rzhNJE+e bk7frci4Af44SW7j3Pc3ibT4dZXmG3BCIzWik93sUWFIAf1exGHJtmvBEUVjjrcY nMXeiG5JnGfaoC5sWmK896sHQhyCl6L8NDtj7YAa0dk1QludMKHqgGh4172JfQGP vaBEqSe+sbBiWBNoIbWA2SiLN7SOJ5QavIdIvu49a7ihryUCrDATOAA5R6LkviGZ YNe8IQU1G1oj6M8Mf3hx0M2bMRjUs0SNLq3fSs2BeCE272e6LRTDapewtBnYwxvA == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 827617E5CA; Wed, 17 Jan 2018 17:52:29 -0500 (EST) From: Thomas Monjalon To: qian.q.xu@intel.com, michael.j.glynn@intel.com, deepak.k.jain@intel.com Cc: dev@dpdk.org, Adrien Mazarguil , hemant.agrawal@nxp.com, bruce.richardson@intel.com Date: Wed, 17 Jan 2018 23:51:57 +0100 Message-ID: <3950879.ikbUWaxXct@xps> In-Reply-To: <35283972.WjYn73NGax@xps> References: <13541534.8OkorCjPcv@xps> <20180115170829.GA4256@6wind.com> <35283972.WjYn73NGax@xps> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] compilation error on Suse 11 - LPM init of anon union 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: , X-List-Received-Date: Wed, 17 Jan 2018 22:52:30 -0000 Sending again with fixed recipient email. 17/01/2018 23:49, Thomas Monjalon: > We need someone from Intel to check on the testing platform please. > It can be decided to drop testing of Suse 11 SP2. > Thanks >=20 > 15/01/2018 18:08, Adrien Mazarguil: > > On Mon, Jan 15, 2018 at 05:18:37PM +0100, Adrien Mazarguil wrote: > > > On Sat, Jan 13, 2018 at 08:14:06PM +0100, Thomas Monjalon wrote: > > > > Hi, > > > >=20 > > > > There is a new compilation error since this commit in LPM: > > > > http://dpdk.org/commit/b2e1c99 > > > > The brace has been removed because unnecessary with anonymous union. > > > >=20 > > > > This union is declared with RTE_STD_C11 for compatibility > > > > with old compilers: > > > > /** C extension macro for environments lacking C11 features. */ > > > > #if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 201112L > > > > #define RTE_STD_C11 __extension__ = =20 > > > > #else > > > > #define RTE_STD_C11 > > > > #endif > > >=20 > > > Yes, however not only for old compilers, e.g. explicitly specifying -= std=3Dc99 > > > on the command-line disables C11 extensions for newer compilers as we= ll. > > >=20 > > > Not specifying anything (like most applications do) simply defaults to > > > whatever standard is deemed "current" for it. > > >=20 > > > In short, RTE_STD_C11 gets expanded as __extension__ when the compile= r isn't > > > in C11 mode, and what follows is therefore an extension to the standa= rd in > > > use (be it C90 or C99). > > >=20 > > > __extension__ remains explicitly used in place of RTE_STD_C11 for thi= ngs > > > that are not even found in C11, namely GNU syntax extensions fall und= er this > > > category. Keep in mind the __extension__ keyword is itself a GNU exte= nsion. > > >=20 > > > > Unfortunately, it does not work on Suse 11 SP2 with GCC 4.5.1: > > > > lib/librte_lpm/rte_lpm.c: In function =E2=80=98add_depth_big_v20= =E2=80=99: > > > > lib/librte_lpm/rte_lpm.c:886:4: error: > > > > unknown field =E2=80=98group_idx=E2=80=99 specified in initializer > > > >=20 > > > > Curiously, the error is exactly the same with ICC 16.0.2: > > > > http://dpdk.org/ml/archives/test-report/2018-January/038443.html > > > > Is it really using different compilers in those 2 tests? > > > >=20 > > > > Someone to check the value of __STDC_VERSION__ with those compilers? > > > > gcc -dM -E -xc /dev/null | grep STDC_VERSION > > > >=20 > > > > Thanks for the help > > >=20 > > > Since this problem only appears in big endian, my suggestion would be= to add > > > RTE_STD_C11 to the anonymous union of struct rte_lpm_tbl_entry_v20 > > > (rte_lpm.h), like its little endian counterpart: > > >=20 > > > #if RTE_BYTE_ORDER =3D=3D RTE_LITTLE_ENDIAN > > > [...] > > > RTE_STD_C11 > > > union { > > > uint8_t next_hop; > > > uint8_t group_idx; > > > }; > > > [...] > > > #else > > > __extension__ > > > struct rte_lpm_tbl_entry_v20 { > > > uint8_t depth :6; > > > uint8_t valid_group :1; > > > uint8_t valid :1; > > > RTE_STD_C11 // <<< Should be added here > > > union { > > > uint8_t group_idx; > > > uint8_t next_hop; > > > }; > > > }; > > >=20 > > > I don't have the adequate test environment to validate this, so please > > > report if it helps and/or submit a patch, thanks. > >=20 > > Looks like I mixed the issue mentioned by the original patch [1] and th= e one > > you found on SuSE, which appears on little endian systems. > >=20 > > Adding RTE_STD_C11 as suggested above is correct but useless since > > __extension__ is part of the parent structure definition anyway, so thi= s is > > not the reason. > >=20 > > Adding -pedantic (but not -std), this issue can be reproduced in a form= or > > another using GCC 4.4 through 4.9 which all default to C90, while GCC 6= =2E3 > > defaults to C11. Without -pendantic, I only managed to reproduce it wit= h GCC > > 4.4 (I don't have 4.5 handy, however it can't be reproduced using 4.6). > >=20 > > The problem with GCC 4.4 and likely 4.5 is basically they do not suppor= t the > > initialization syntax used in rte_lpm.c. Extra { } are needed even with > > unnamed union fields, there's no way around that AFAIK. > >=20 > > Since we likely don't want to revert [1] and although GCC 4.5 is not > > recommended (4.9 minimum according to [2]), I suggest using a more > > conventional initialization for this particular field, e.g. replacing: > > =20 > > struct rte_lpm_tbl_entry_v20 new_tbl24_entry =3D { > > .group_idx =3D (uint8_t)tbl8_group_index, > > .valid =3D VALID, > > .valid_group =3D 1, > > .depth =3D 0, > > }; > >=20 > > With something like: > >=20 > > struct rte_lpm_tbl_entry_v20 new_tbl24_entry =3D { > > .valid =3D VALID, > > .valid_group =3D 1, > > .depth =3D 0, > > }; > >=20 > > /* Anonymous union field initialized outside (GCC < 4.6 compatibility)= =2E */ > > new_tbl24_entry.group_idx =3D (uint8_t)tbl8_group_index; > >=20 > > Your call. > >=20 > > [1] http://dpdk.org/commit/b2e1c99 > > [2] http://dpdk.org/doc/guides/linux_gsg/sys_reqs.html