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 44FFB1B2CF for ; Wed, 17 Jan 2018 23:50:24 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id CDE9120AF5; Wed, 17 Jan 2018 17:50:23 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 17 Jan 2018 17:50:23 -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=aSuDkCX/FH2Ys8lKOpzG/j5j2i l+kkiYyX0dtaZ6UfE=; b=WMEkyqFPyLJTakvJeUxuf7W2ieCYmmWYV+E0j8uRGf 8AHbI8KtRqvL4GNVa1HtqVcKa+L3LhkDmEUTckhplhng1V5vkFc4l2wudbC43kW6 x0g8eU5ehzJKuO6iWsAl2KbJsp0ohr3eWn/q/eYV5qbgzixWeDviXqh2fXsxyToT 0= 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=aSuDkC X/FH2Ys8lKOpzG/j5j2il+kkiYyX0dtaZ6UfE=; b=mfWMq2s+cjegTWA+C1APrf aW8VTZHo8roXHg+eCLuDbJLwY5bmf/8WJtpwP7ZAuMcZGv2ZHW+IselWLGathZEO +gCR5u/FWfzTHh0KmRqEoGYchiQ6aidEeQneudcGjHGhy9clyL/tPNIehcYmcthn zG7O+J8XMwMyhKAVYWDGXD3rCKZFJpVoBzY0qb97QqwxT7/Q8Ia6EpZGFFW8tZr9 8UNlvClrjfqFrC7oRW5nq9dfEsPIQjN1dG8IU9Pl6d52RDYVrAvrdC8z/0Lwcnxa S8uz4wXh5JgOWWFvGCYEM3TX3UfsMyVfIY6oOJzTLZ4XOh3vmqkXT5FkPQ7R5brQ == 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 6F06324608; Wed, 17 Jan 2018 17:50:23 -0500 (EST) From: Thomas Monjalon To: qian.q.xu@intel.com, mike.a.polehn@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:49:50 +0100 Message-ID: <35283972.WjYn73NGax@xps> In-Reply-To: <20180115170829.GA4256@6wind.com> References: <13541534.8OkorCjPcv@xps> <20180115161837.GY4256@6wind.com> <20180115170829.GA4256@6wind.com> 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:50:24 -0000 We need someone from Intel to check on the testing platform please. It can be decided to drop testing of Suse 11 SP2. Thanks 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 -st= d=3Dc99 > > on the command-line disables C11 extensions for newer compilers as well. > >=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 compiler = isn't > > in C11 mode, and what follows is therefore an extension to the standard= in > > use (be it C90 or C99). > >=20 > > __extension__ remains explicitly used in place of RTE_STD_C11 for things > > that are not even found in C11, namely GNU syntax extensions fall under= this > > category. Keep in mind the __extension__ keyword is itself a GNU extens= ion. > >=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 t= o 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 the = 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 this = 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.3 > defaults to C11. Without -pendantic, I only managed to reproduce it with = 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 support = 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). = */ > 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