From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f173.google.com (mail-wr0-f173.google.com [209.85.128.173]) by dpdk.org (Postfix) with ESMTP id A36B82A63 for ; Mon, 15 Jan 2018 18:08:41 +0100 (CET) Received: by mail-wr0-f173.google.com with SMTP id f11so1963162wre.4 for ; Mon, 15 Jan 2018 09:08:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=/FEcu4ApSI90XTxL7XvI14PVQj0ST8ECY7WvugZibdA=; b=y9WwEweS2cZjYy2hxA5JmJTkm+FWpw5MFSBuliktSmYvZrMnsbJ/vYABsKq/Gmwb/S v1Tw7ZmyxsumwDYAHZMlESb6JQFNQC4LYVCvFaNpwMXkWTBsKybsunCTlid6JV1aJCMM 4BPzWOj/yiODSMFR5jy+iZ1+gaIWWUSMja/TNGRqQWqiXL26UCzbSA5DjTkTymHnXh5t HZnQ/5BOTdpb2yugdy4vtkJnnEWQG3d7DKsMWXW6Jx2+/IQ712C7uNhh62ARZCpTjJSp GLr2KJIrA5LGGF0lxsiDeWTQp8tc0kcwP73nFmrPq0Ne5iDn2o1LzfOCL3Rmb+4DeRk7 6m/A== 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:content-transfer-encoding :in-reply-to; bh=/FEcu4ApSI90XTxL7XvI14PVQj0ST8ECY7WvugZibdA=; b=E+QpxVauuK7XXEu8SoukfVbAZkT2lD2PTgYRL6v2YNtTokj223pCQBNi7V90tDx5FW cGQk8mdAHkePlejr0prjxA+QC3skqABz9p5jJl/bgvpw5BtMWbvRdl4URtbNp/7u1lGp KgTBg2F7RUExTwvh2xsot6bl3/X5y6GXkeerxelF1AR69zzLqjw187VHKsuIITT6X9qn XpShvsLZGiZ+HszpIFkEQzQVgl3QM52tJyQGoqZCrVkZab0RshLqe6gYYuxkB3aALBri znCRsj1CbQLa8BIH6F/rKL/YoZTphMoxX+3tMUTbGWuHjqYNp+8vyp3uo7Dw14eAICHw zpDQ== X-Gm-Message-State: AKwxyteQXdWAuStahD/ZIbcAZMBDPZtmiLFeUeIg0QvcPVZK9RgpRzBP YuC9mVMomndR2i3QsthtulrNvQ== X-Google-Smtp-Source: ACJfBosBaOVtW80IKzalkF5hN9yITlWr+FMP7goLRXhJu3odo0Zsumv+A3etBthjMJ2TT9F6b16xew== X-Received: by 10.223.139.218 with SMTP id w26mr11567229wra.67.1516036121337; Mon, 15 Jan 2018 09:08:41 -0800 (PST) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id s19sm116641wrg.29.2018.01.15.09.08.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jan 2018 09:08:40 -0800 (PST) Date: Mon, 15 Jan 2018 18:08:29 +0100 From: Adrien Mazarguil To: Thomas Monjalon Cc: qian.q.xu@intel.com, dev@dpdk.org, hemant.agrawal@nxp.com, bruce.richardson@intel.com Message-ID: <20180115170829.GA4256@6wind.com> References: <13541534.8OkorCjPcv@xps> <20180115161837.GY4256@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180115161837.GY4256@6wind.com> 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: Mon, 15 Jan 2018 17:08:41 -0000 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 -- Adrien Mazarguil 6WIND