From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id C067A2A9 for ; Mon, 1 Dec 2014 12:25:02 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 01 Dec 2014 03:22:23 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,493,1413270000"; d="scan'208";a="646149682" Received: from bricha3-mobl3.ger.corp.intel.com ([10.243.20.36]) by orsmga002.jf.intel.com with SMTP; 01 Dec 2014 03:24:59 -0800 Received: by (sSMTP sendmail emulation); Mon, 01 Dec 2014 11:24:58 +0025 Date: Mon, 1 Dec 2014 11:24:58 +0000 From: Bruce Richardson To: Neil Horman Message-ID: <20141201112458.GD4856@bricha3-MOBL3> References: <1417188660-14587-1-git-send-email-bruce.richardson@intel.com> <20141130010514.GA19479@localhost.localdomain> <547C3052.4080106@6wind.com> <20141201111817.GA15135@hmsreliant.think-freely.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141201111817.GA15135@hmsreliant.think-freely.org> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH] ixgbe: fix clang compile - remove truncation errors X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 11:25:03 -0000 On Mon, Dec 01, 2014 at 06:18:17AM -0500, Neil Horman wrote: > On Mon, Dec 01, 2014 at 10:09:38AM +0100, Olivier MATZ wrote: > > Hi Bruce, Hi Neil, > > > > On 11/30/2014 02:05 AM, Neil Horman wrote: > > > On Fri, Nov 28, 2014 at 03:31:00PM +0000, Bruce Richardson wrote: > > >> When compiling with clang, errors were being emitted due to truncation > > >> of values when assigning to the tx_offload_mask bit fields. > > >> > > >> dpdk.org/lib/librte_pmd_ixgbe/ixgbe_rxtx.c:404:27: fatal error: implicit truncation from 'int' to bitfield changes value from -1 to 127 [-Wbitfield-constant-conversion] > > >> tx_offload_mask.l2_len = ~0; > > >> > > >> The fix proposed here is to define a static const value of the same type > > >> with all fields set to 1s, and use that instead of constants for assigning to. > > >> > > >> Other options would be to explicitily define the suitable constants that > > >> would not truncate for each individual field e.g. 0x7f for l2_len, 0x1FF > > >> for l3_len, etc., but this solution here has the advantage that it works > > >> without any changes to values if the field sizes are ever modified. > > >> > > >> Signed-off-by: Bruce Richardson > > >> --- > > >> lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 29 +++++++++++++++-------------- > > >> 1 file changed, 15 insertions(+), 14 deletions(-) > > >> > > >> diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c > > >> index 8559ef6..4f71194 100644 > > >> --- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c > > >> +++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c > > >> @@ -367,6 +367,7 @@ ixgbe_set_xmit_ctx(struct igb_tx_queue* txq, > > >> volatile struct ixgbe_adv_tx_context_desc *ctx_txd, > > >> uint64_t ol_flags, union ixgbe_tx_offload tx_offload) > > >> { > > >> + static const union ixgbe_tx_offload offload_allones = { .data = ~0 }; > > > Do you want to make this a static data structure? If you make it a macro like > > > this: > > > #define ALLONES {.data = ~0} > > > Then you save the extra data space in the .data area (not that its that much), > > > and you can define it in a header file and use it in multiple c files (if you > > > need to) > > > > I found that the following code works: > > > > tx_offload_mask.l2_len |= ~0; > > > > (note the '|=' instead of '=') > > > How exactly does this work? does the or operator imply some level of type > promotion that the assignment doesn't to avoid the truncation? > Neil > For any aithmetic, and presumably logical, operation on two values, any values smaller than "int" are promoted to type int before the operation takes place. I believe the exact rules for this are in the C specs e.g. C99. /Bruce > > I would avoid to create a macro. What do you think? > > > > Regards, > > Olivier > >