From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id C496A1D7; Tue, 6 Nov 2018 21:27:24 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 3C79822062; Tue, 6 Nov 2018 15:27:24 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Tue, 06 Nov 2018 15:27:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=A9EDgEb0l9tL+eIMJp7nMnYLn6fvMsMjrgWpyOU8vWk=; b=AuODs/u2V1OD OMWxTAk+WXq6GSg5ZhUi2xGRGAOylchEItUvtHDc2lCbbvSVDmcHFWoGiDgs0kcS UDX+vua0kJDUZjHB8WzcRL4A33pgIhotk5Bl5xtNXnfUIbxm0l/JqIqB0lK7A6mP U5+qTZkDxFTQkbU0OKBpUbEsRo5nd+0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=A9EDgEb0l9tL+eIMJp7nMnYLn6fvMsMjrgWpyOU8v Wk=; b=tOPJfa6AppV0SampY0b1UBcERkPwN0H6JFt8fBjBf+q1ap29t9lCkPf/d 9bojJUUHBTWdUgWFGk3kqlZaOgsyW3MBlflLuqD3SvE9+cKj9byDujgjaTeTge+H isvwQEZJ78fxRoCtK/0uJFrSRIwXAlHb95MVDCwoA+jk+NBLzG1ZH86qZOdSufDu eZVAMz62IkTgtBMuql/Jx8cx1jWUmtOaBm9w3IwLD+V2APG4leWWuj4w8TVYMyxk tmfk/sHsWTyhVUlQDtiss5hqhZJGDEMvxGCuK6He7Z+Uq1HtL/JnmcqlQAIFKE5g mTCwpv36VrX7ZocjaDJUvMCm0z4TQ== X-ME-Sender: X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 5530FE4430; Tue, 6 Nov 2018 15:27:22 -0500 (EST) From: Thomas Monjalon To: Jerin Jacob Cc: "dev@dpdk.org" , "Jacob, Jerin" , "stable@dpdk.org" Date: Tue, 06 Nov 2018 21:27:19 +0100 Message-ID: <59314752.LC5aAjuh3R@xps> In-Reply-To: <20181106133127.GA29301@jerin> References: <20181106114435.14770-1-jerin.jacob@caviumnetworks.com> <3520386.84pXejHKmD@xps> <20181106133127.GA29301@jerin> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH] eal: fix build issue 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: Tue, 06 Nov 2018 20:27:25 -0000 06/11/2018 14:31, Jerin Jacob: > From: Thomas Monjalon > > 06/11/2018 12:45, Jerin Jacob: > > > Some toolchain has fls() definition in string.h as argument type int, > > > which is conflicting uint32_t argument type. > > > > > > /export/dpdk.org/lib/librte_eal/common/rte_reciprocal.c:47:19: > > > error: conflicting types for =E2=80=98fls=E2=80=99 > > > static inline int fls(uint32_t x) > > > ^~~ > > > > > > /opt/marvell-tools-201/aarch64-marvell-elf/include/strings.h:59:6: > > > note: previous declaration of =E2=80=98fls=E2=80=99 was here > > > int fls(int) __pure2; > > > > > > FreeBSD string.h also has fls() with argument as int type. > > > https://www.freebsd.org/cgi/man.cgi?query=3Dfls&sektion=3D3 > > > > > > Fixing the conflict by renaming internal function as __fls > >=20 > > Why not rte_fls? Would it be more future proof? >=20 > Agreed. There are two instance of fls in dpdk code base now, >=20 > 1) lib/librte_eal/common/rte_reciprocal.c takes uint32_t > 2) drivers/net/fm10k/fm10k_ethdev.c has macro, used with uint16_t as > argument. >=20 > Should we make it as macro or follow libc prototype where argument is > int. >=20 > Something like below, >=20 > static inline int > rte_fls(int x) > { > return (x =3D=3D 0) ? 0 : sizeof(x) * 8 - __builtin_clz(x); > } I tend to think that using uint32_t parameter would be more useful in DPDK.