From: Thomas Monjalon <thomas@monjalon.net>
To: qian.q.xu@intel.com, mike.a.polehn@intel.com, deepak.k.jain@intel.com
Cc: dev@dpdk.org, Adrien Mazarguil <adrien.mazarguil@6wind.com>,
hemant.agrawal@nxp.com, bruce.richardson@intel.com
Subject: Re: [dpdk-dev] compilation error on Suse 11 - LPM init of anon union
Date: Wed, 17 Jan 2018 23:49:50 +0100 [thread overview]
Message-ID: <35283972.WjYn73NGax@xps> (raw)
In-Reply-To: <20180115170829.GA4256@6wind.com>
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,
> > >
> > > 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.
> > >
> > > 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__
> > > #else
> > > #define RTE_STD_C11
> > > #endif
> >
> > Yes, however not only for old compilers, e.g. explicitly specifying -std=c99
> > on the command-line disables C11 extensions for newer compilers as well.
> >
> > Not specifying anything (like most applications do) simply defaults to
> > whatever standard is deemed "current" for it.
> >
> > 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).
> >
> > __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 extension.
> >
> > > Unfortunately, it does not work on Suse 11 SP2 with GCC 4.5.1:
> > > lib/librte_lpm/rte_lpm.c: In function ‘add_depth_big_v20’:
> > > lib/librte_lpm/rte_lpm.c:886:4: error:
> > > unknown field ‘group_idx’ specified in initializer
> > >
> > > 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?
> > >
> > > Someone to check the value of __STDC_VERSION__ with those compilers?
> > > gcc -dM -E -xc /dev/null | grep STDC_VERSION
> > >
> > > Thanks for the help
> >
> > 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:
> >
> > #if RTE_BYTE_ORDER == 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;
> > };
> > };
> >
> > I don't have the adequate test environment to validate this, so please
> > report if it helps and/or submit a patch, thanks.
>
> 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.
>
> 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.
>
> 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).
>
> 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.
>
> 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:
>
> struct rte_lpm_tbl_entry_v20 new_tbl24_entry = {
> .group_idx = (uint8_t)tbl8_group_index,
> .valid = VALID,
> .valid_group = 1,
> .depth = 0,
> };
>
> With something like:
>
> struct rte_lpm_tbl_entry_v20 new_tbl24_entry = {
> .valid = VALID,
> .valid_group = 1,
> .depth = 0,
> };
>
> /* Anonymous union field initialized outside (GCC < 4.6 compatibility). */
> new_tbl24_entry.group_idx = (uint8_t)tbl8_group_index;
>
> Your call.
>
> [1] http://dpdk.org/commit/b2e1c99
> [2] http://dpdk.org/doc/guides/linux_gsg/sys_reqs.html
next prev parent reply other threads:[~2018-01-17 22:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-13 19:14 Thomas Monjalon
2018-01-15 16:18 ` Adrien Mazarguil
2018-01-15 17:08 ` Adrien Mazarguil
2018-01-17 22:49 ` Thomas Monjalon [this message]
2018-01-17 22:51 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=35283972.WjYn73NGax@xps \
--to=thomas@monjalon.net \
--cc=adrien.mazarguil@6wind.com \
--cc=bruce.richardson@intel.com \
--cc=deepak.k.jain@intel.com \
--cc=dev@dpdk.org \
--cc=hemant.agrawal@nxp.com \
--cc=mike.a.polehn@intel.com \
--cc=qian.q.xu@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).