From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.warmcat.com (mail.warmcat.com [163.172.24.82]) by dpdk.org (Postfix) with ESMTP id 833111BD94 for ; Mon, 14 May 2018 02:02:46 +0200 (CEST) To: Thomas Monjalon Cc: dev@dpdk.org References: <152609021699.121661.5295227351721865436.stgit@localhost.localdomain> <152609040775.121661.12633606299514774674.stgit@localhost.localdomain> <10112839.slRIOooWqA@xps> From: Andy Green Message-ID: Date: Mon, 14 May 2018 08:02:27 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 In-Reply-To: <10112839.slRIOooWqA@xps> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v3 17/24] rte_byteorder.h: explicit cast for return promotion 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, 14 May 2018 00:02:46 -0000 On 05/14/2018 12:59 AM, Thomas Monjalon wrote: > 12/05/2018 04:00, Andy Green: >> --- a/lib/librte_eal/common/include/generic/rte_byteorder.h >> +++ b/lib/librte_eal/common/include/generic/rte_byteorder.h >> @@ -123,7 +123,7 @@ typedef uint64_t rte_le64_t; /**< 64-bit little-endian value. */ >> static inline uint16_t >> rte_constant_bswap16(uint16_t x) >> { >> - return RTE_STATIC_BSWAP16(x); >> + return (uint16_t)RTE_STATIC_BSWAP16((uint16_t)x); >> } > > x is already uint16_t, and RTE_STATIC_BSWAP16 is already casting to uint16_t. > So why these casts are needed? After winding dpdk back inside lagopus without this patch and recooking everything... In file included from /projects/lagopus/src/dpdk/build/include/rte_byteorder.h:15, from /projects/lagopus/src/dataplane/dpdk/pktbuf.h:27, from ./ofproto/mbtree.c:50: /projects/lagopus/src/dpdk/build/include/generic/rte_byteorder.h: In function 'rte_constant_bswap16': /projects/lagopus/src/dpdk/build/include/generic/rte_byteorder.h:54:45: warning: conversion from 'int' to 'uint16_t' {aka 'short unsigned int'} may change value [-Wconversion] ((((uint16_t)(v) & UINT16_C(0x00ff)) << 8) | \ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~ (((uint16_t)(v) & UINT16_C(0xff00)) >> 8)) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /projects/lagopus/src/dpdk/build/include/generic/rte_byteorder.h:126:9: note: in expansion of macro 'RTE_STATIC_BSWAP16' return RTE_STATIC_BSWAP16(x); ^~~~~~~~~~~~~~~~~~ > And why not in rte_constant_bswap32/64? It's likely also needed there. I removed the second cast and then repeated the fix on 32/64 as well. GCC8 building lagopus blowing chunks is my only insight into these api header problems in dpdk. It only blew on bswap16. I simply want to build lagopus with latest pieces to assess how much risk signing up to use lagopus (and its dependencies) ongoing gets me into. So my goal is fix all the build issues around that and then why not provide the patches to the projects since they are done by then. (My lagopus fixes will have no meaning unless the dpdk fixes get in first, so I defer interacting with them). I can get that to build (I think... I have to pin the dpdk subproject, make clean, make dpdk and then finally make to see the warnings repeatably) with master dpdk now with my dpdk series of ~45 patches, but it requires 25 patches on lagopus and there are still a ton of warnings to clean out and an api change about color / metering I just hacked out for now. I didn't look too closely yet but maybe some more dpdk header usage issues to come. -Andy