| Message ID | 20181106114435.14770-1-jerin.jacob@caviumnetworks.com (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Delegated to: | Thomas Monjalon |
| Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2A0052D13; Tue, 6 Nov 2018 12:45:05 +0100 (CET) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-eopbgr810080.outbound.protection.outlook.com [40.107.81.80]) by dpdk.org (Postfix) with ESMTP id 25D4C2BE2; Tue, 6 Nov 2018 12:45:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RLnohjhFDLjPcQmDKQKR5c3kF1RyGAbQcKgvzgcaw5I=; b=jFD4RtsOfS10Oq5TujjJ/716vCs7RbyPvEM2nHN/rFpg/YjVGq4mPE8l5NSDMQYaMfcQHO3KsB3QvO8LHxWcurtzbATTygiMKgTMpbIJhrLrxwW4CmXF3atmJe4oIOR8hhRkrpQl8yW77E12ef7mo7ZeUqT1S3VuVHq5qBZ0C6A= Received: from BYAPR07MB4997.namprd07.prod.outlook.com (52.135.238.214) by BYAPR07MB4837.namprd07.prod.outlook.com (52.135.203.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.26; Tue, 6 Nov 2018 11:45:01 +0000 Received: from BYAPR07MB4997.namprd07.prod.outlook.com ([fe80::2d56:eab:242f:fdfc]) by BYAPR07MB4997.namprd07.prod.outlook.com ([fe80::2d56:eab:242f:fdfc%3]) with mapi id 15.20.1294.034; Tue, 6 Nov 2018 11:45:01 +0000 From: Jerin Jacob <jerin.jacob@caviumnetworks.com> To: "dev@dpdk.org" <dev@dpdk.org> CC: "thomas@monjalon.net" <thomas@monjalon.net>, "Jacob, Jerin" <Jerin.JacobKollanukkaran@cavium.com>, "stable@dpdk.org" <stable@dpdk.org> Thread-Topic: [dpdk-dev] [PATCH] eal: fix build issue Thread-Index: AQHUdcYmle+EEicknUOer0EpVc/5dw== Date: Tue, 6 Nov 2018 11:45:01 +0000 Message-ID: <20181106114435.14770-1-jerin.jacob@caviumnetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [111.93.218.67] x-clientproxiedby: BM1PR0101CA0043.INDPRD01.PROD.OUTLOOK.COM (2603:1096:b00:1a::29) To BYAPR07MB4997.namprd07.prod.outlook.com (2603:10b6:a03:5b::22) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR07MB4837; 6:8HJ8C7771fEf1rJG9pjhSjyGIYGYqLFzZ2zsIjQ0OWzCfWU5pL+u7z2H0YpHdqdl6+LaCHGAtdAOFMTeLk8Y2op0BQ5xZX2Zn+RbcE2shH4WZBDTMwudjgcobxiyLvPqRS+HFYOoozJm7pa1ocvcr7uGO/jAEXoyCrwJs7KUOaM9j4usWJVTFr9M0I6XjYan9cpmyOSo/UMzTi3Vqj25/LUH+GIBBBRcteVM6VRVyWxIVcJnQrC1/Fd6TIJJHmfxL1yptcjErIuu6RDJj0vKPqU+mPHCOm4cMpfMNKUJ0OZj3NKbsbERTeF3WDP/9cCcKGCh4kvlOsSkhozL8/dXjUrvxwVWU9hwyUONi7jtg2yDBYC9Ml3qTpTphYAuLL3f9ckFIoQenTJEtDpAtMS2Lk9UbtYPU9mBigqgaA/TS6w6C4x2FuO0rz6/uehkhALHxr4lPHPaf1UFahlPpn2+Hw==; 5:wJejRSI/JolQt0xSC4ugrzSfWZHIX1rt8J43ay19wK9qYz5StQ9wIVwwxWdMKfs931WUt6K+9ibq3YwUzc8JJijEpRkIDt4O/120Xyr4ea9F2sfRKoX1/ZAtDZsKxHAHPrTwAIaD+FeSMBM9rhR7IPocFi4bS3639UkjMsrOJRQ=; 7:4TabCYTFbmERRAPCaMx2GrmL7/hE+8sJTaBRLF25y0sdse4e9085WZkvkPfGcsoSYsA7mE9btWeXOCjHP8d/NOjzILHK/mMjICT8Z+S12UQrAwq4SC695kPlBywWs0zWbSv9y0Ic4CUfH7l7gwPAdg== x-ms-office365-filtering-correlation-id: 79aed3f2-c7aa-4a54-5fc0-08d643dd48ec x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:BYAPR07MB4837; x-ms-traffictypediagnostic: BYAPR07MB4837: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jerin.JacobKollanukkaran@cavium.com; x-microsoft-antispam-prvs: <BYAPR07MB483717B812758C7C7BE2CDC4E3CB0@BYAPR07MB4837.namprd07.prod.outlook.com> x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231382)(944501410)(52105095)(3002001)(10201501046)(93006095)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:BYAPR07MB4837; BCL:0; PCL:0; RULEID:; SRVR:BYAPR07MB4837; x-forefront-prvs: 0848C1A6AA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(346002)(376002)(366004)(136003)(39850400004)(396003)(189003)(199004)(186003)(42882007)(1857600001)(99286004)(2616005)(486006)(476003)(6916009)(386003)(6506007)(52116002)(26005)(106356001)(102836004)(66066001)(2351001)(36756003)(966005)(54906003)(68736007)(6116002)(105586002)(14454004)(5660300001)(25786009)(2906002)(7736002)(71200400001)(4326008)(305945005)(71190400001)(3846002)(72206003)(97736004)(5640700003)(2501003)(6436002)(1076002)(6486002)(2900100001)(478600001)(316002)(78486014)(256004)(6306002)(8676002)(53936002)(81156014)(1730700003)(81166006)(6512007)(8936002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR07MB4837; H:BYAPR07MB4997.namprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: gTHHauOTRs4dIagIh4tWJAjBQJvT/pY6CldJsbu9isvVpN7xnRlsQ0ZkY3CcHS/+FQVKL9wqxUkSHwXxJWmFw45x+cYRY2Hpjq9KuWuUMf+hNgmG2xnLOctNGUS9x4Rw9UFq+WMfnLfLSdASa0Z4Sh42GkcWU+EyVYdVmCyCQO194NkuIC5E2S1AN19LXkOyTrPEZk95OzVRiQizk9KH4EwhtJE3OpK9Bs+5C2I3YkKMa4EUzA+x9skfwux5dWFf1ltiq26y5smjwknyEnjp16hQAtXVsg1JWn+UN6zJiy3fNAUTAGCd49/JZ0P7hhgIBuKl0kmtmpTZt5J58wW2OCt3N7EAPnHF6PrcdsIs75I= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <1F398B3B1107CE448FED305A2E61145A@namprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-Network-Message-Id: 79aed3f2-c7aa-4a54-5fc0-08d643dd48ec X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2018 11:45:01.4641 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR07MB4837 Subject: [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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
| Series |
eal: fix build issue
|
|
Checks
| Context | Check | Description |
|---|---|---|
| ci/Intel-compilation | success | Compilation OK |
Commit Message
Jerin Jacob
Nov. 6, 2018, 11:45 a.m. UTC
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 ‘fls’
static inline int fls(uint32_t x)
^~~
/opt/marvell-tools-201/aarch64-marvell-elf/include/strings.h:59:6:
note: previous declaration of ‘fls’ 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=fls&sektion=3
Fixing the conflict by renaming internal function as __fls
Fixes: ffe3ec811ef5 ("sched: introduce reciprocal divide")
Cc: stable@dpdk.org
Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
---
lib/librte_eal/common/rte_reciprocal.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Comments
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 ‘fls’ > static inline int fls(uint32_t x) > ^~~ > > /opt/marvell-tools-201/aarch64-marvell-elf/include/strings.h:59:6: > note: previous declaration of ‘fls’ 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=fls&sektion=3 > > Fixing the conflict by renaming internal function as __fls Why not rte_fls? Would it be more future proof?
-----Original Message----- > Date: Tue, 06 Nov 2018 13:29:19 +0100 > From: Thomas Monjalon <thomas@monjalon.net> > To: Jerin Jacob <jerin.jacob@caviumnetworks.com> > Cc: "dev@dpdk.org" <dev@dpdk.org>, "Jacob, Jerin" > <Jerin.JacobKollanukkaran@cavium.com>, "stable@dpdk.org" <stable@dpdk.org> > Subject: Re: [dpdk-dev] [PATCH] eal: fix build issue > > > 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 ‘fls’ > > static inline int fls(uint32_t x) > > ^~~ > > > > /opt/marvell-tools-201/aarch64-marvell-elf/include/strings.h:59:6: > > note: previous declaration of ‘fls’ 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=fls&sektion=3 > > > > Fixing the conflict by renaming internal function as __fls > > Why not rte_fls? Would it be more future proof? Agreed. There are two instance of fls in dpdk code base now, 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. Should we make it as macro or follow libc prototype where argument is int. Something like below, static inline int rte_fls(int x) { return (x == 0) ? 0 : sizeof(x) * 8 - __builtin_clz(x); } > >
06/11/2018 14:31, Jerin Jacob: > From: Thomas Monjalon <thomas@monjalon.net> > > 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 ‘fls’ > > > static inline int fls(uint32_t x) > > > ^~~ > > > > > > /opt/marvell-tools-201/aarch64-marvell-elf/include/strings.h:59:6: > > > note: previous declaration of ‘fls’ 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=fls&sektion=3 > > > > > > Fixing the conflict by renaming internal function as __fls > > > > Why not rte_fls? Would it be more future proof? > > Agreed. There are two instance of fls in dpdk code base now, > > 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. > > Should we make it as macro or follow libc prototype where argument is > int. > > Something like below, > > static inline int > rte_fls(int x) > { > return (x == 0) ? 0 : sizeof(x) * 8 - __builtin_clz(x); > } I tend to think that using uint32_t parameter would be more useful in DPDK.
diff --git a/lib/librte_eal/common/rte_reciprocal.c b/lib/librte_eal/common/rte_reciprocal.c index d81b11db6..f2c7453d2 100644 --- a/lib/librte_eal/common/rte_reciprocal.c +++ b/lib/librte_eal/common/rte_reciprocal.c @@ -44,7 +44,7 @@ /* find largest set bit. * portable and slow but does not matter for this usage. */ -static inline int fls(uint32_t x) +static inline int __fls(uint32_t x) { int b; @@ -62,7 +62,7 @@ struct rte_reciprocal rte_reciprocal_value(uint32_t d) uint64_t m; int l; - l = fls(d - 1); + l = __fls(d - 1); m = ((1ULL << 32) * ((1ULL << l) - d)); m /= d;