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 0A5F17E75 for ; Thu, 4 Dec 2014 11:21:31 +0100 (CET) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 04 Dec 2014 02:20:22 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,514,1413270000"; d="scan'208";a="618488259" Received: from kmsmsx152.gar.corp.intel.com ([172.21.73.87]) by orsmga001.jf.intel.com with ESMTP; 04 Dec 2014 02:21:29 -0800 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by KMSMSX152.gar.corp.intel.com (172.21.73.87) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 4 Dec 2014 18:21:28 +0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.5]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 18:21:27 +0800 From: "Qiu, Michael" To: Thomas Monjalon Thread-Topic: [PATCH v2] Fix two compile issues with i686 platform Thread-Index: AQHQDtC2sNKGP0Pvek+HmA2FP8qVgQ== Date: Thu, 4 Dec 2014 10:21:26 +0000 Message-ID: <533710CFB86FA344BFBF2D6802E60286C9CB12@SHSMSX101.ccr.corp.intel.com> References: <1417329845-7482-1-git-send-email-michael.qiu@intel.com> <20141203154029.GA6340@bricha3-MOBL3> <533710CFB86FA344BFBF2D6802E60286C9C8C7@SHSMSX101.ccr.corp.intel.com> <3274707.l214P3fVjn@xps13> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" , "chaozhu@linux.vnet.ibm.com" Subject: Re: [dpdk-dev] [PATCH v2] Fix two compile issues with i686 platform 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: Thu, 04 Dec 2014 10:21:32 -0000 On 12/4/2014 5:05 PM, Thomas Monjalon wrote:=0A= > 2014-12-04 02:49, Qiu, Michael:=0A= >> On 12/3/2014 11:40 PM, Richardson, Bruce wrote:=0A= >>> On Wed, Dec 03, 2014 at 04:10:23PM +0800, Michael Qiu wrote:=0A= >>>> lib/librte_eal/linuxapp/eal/eal_memory.c:324:4: error: comparison=0A= >>>> is always false due to limited range of data type [-Werror=3Dtype-limi= ts]=0A= >>>> || (hugepage_sz =3D=3D RTE_PGSIZE_16G)) {=0A= >>>> ^=0A= >>>> cc1: all warnings being treated as errors=0A= >>>>=0A= >>>> lib/librte_eal/linuxapp/eal/eal.c(461): error #2259: non-pointer=0A= >>>> conversion from "long long" to "void *" may lose significant bits=0A= >>>> RTE_PTR_ALIGN_CEIL((uintptr_t)addr, RTE_PGSIZE_16M);=0A= >>>>=0A= >>>> This was introuduced by commit b77b5639:=0A= >>>> mem: add huge page sizes for IBM Power=0A= >>>>=0A= >>>> The root cause is that size_t and uintptr_t are 32-bit in i686=0A= >>>> platform, but RTE_PGSIZE_16M and RTE_PGSIZE_16G are always 64-bit.=0A= >>>>=0A= >>>> Define RTE_PGSIZE_16G only in 64 bit platform to avoid=0A= >>>> this issue.=0A= >>>>=0A= >>>> Signed-off-by: Michael Qiu =0A= >>> Minor comment below.=0A= >>>=0A= >>> Acked-by: Bruce Richardson =0A= >>>=0A= >>>> ---=0A= >>>> app/test/test_memzone.c | 18 ++++++++++++------=0A= >>>> lib/librte_eal/common/eal_common_memzone.c | 2 ++=0A= >>>> lib/librte_eal/common/include/rte_memory.h | 14 ++++++++------=0A= >>>> lib/librte_eal/linuxapp/eal/eal_memory.c | 12 +++++-------=0A= >>>> 4 files changed, 27 insertions(+), 19 deletions(-)=0A= >>>>=0A= >>> ... snip ...=0A= >>>> --- a/lib/librte_eal/common/include/rte_memory.h=0A= >>>> +++ b/lib/librte_eal/common/include/rte_memory.h=0A= >>>> @@ -53,12 +53,14 @@ extern "C" {=0A= >>>> #endif=0A= >>>> =0A= >>>> enum rte_page_sizes {=0A= >>>> - RTE_PGSIZE_4K =3D 1ULL << 12,=0A= >>>> - RTE_PGSIZE_2M =3D 1ULL << 21,=0A= >>>> - RTE_PGSIZE_1G =3D 1ULL << 30,=0A= >>>> - RTE_PGSIZE_64K =3D 1ULL << 16,=0A= >>>> - RTE_PGSIZE_16M =3D 1ULL << 24,=0A= >>>> - RTE_PGSIZE_16G =3D 1ULL << 34=0A= >>>> + RTE_PGSIZE_4K =3D 1UL << 12,=0A= >>>> + RTE_PGSIZE_2M =3D 1UL << 21,=0A= >>>> + RTE_PGSIZE_1G =3D 1UL << 30,=0A= >>>> + RTE_PGSIZE_64K =3D 1UL << 16,=0A= >>>> + RTE_PGSIZE_16M =3D 1UL << 24,=0A= >>>> +#ifdef RTE_ARCH_64=0A= >>>> + RTE_PGSIZE_16G =3D 1ULL << 34=0A= >>> you don't need the "LL" here as long type is 64-bits on 64-bit systems.= Changing=0A= >>> it to 1UL << 34 will keep all entries consistent.=0A= >> Hi Thomas,=0A= >>=0A= >> Should I resend V3 patch to modify this or you can do it when you plan= =0A= >> to merge this patch?=0A= > I could do the change by myself. But given that you had some problems to = send=0A= > the patch to the mailing list, please send the v3 to everyone.=0A= > Then a review from Chao would be appreciated.=0A= =0A= OK, I will send V3 to everyone.=0A= =0A= Thanks,=0A= Michael=0A= >=0A= > Thanks=0A= =0A=