DPDK patches and discussions
 help / color / mirror / Atom feed
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

  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).