From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 849767E75 for ; Thu, 4 Dec 2014 03:51:22 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 03 Dec 2014 18:51:13 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,512,1413270000"; d="scan'208";a="632398748" Received: from kmsmsx151.gar.corp.intel.com ([172.21.73.86]) by fmsmga001.fm.intel.com with ESMTP; 03 Dec 2014 18:51:11 -0800 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by KMSMSX151.gar.corp.intel.com (172.21.73.86) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 4 Dec 2014 10:49:26 +0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.182]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 10:49:25 +0800 From: "Qiu, Michael" To: "thomas.monjalon@6wind.com" , Michael Qiu , "Richardson, Bruce" Thread-Topic: [PATCH v2] Fix two compile issues with i686 platform Thread-Index: AQHQDtC2sNKGP0Pvek+HmA2FP8qVgQ== Date: Thu, 4 Dec 2014 02:49:24 +0000 Message-ID: <533710CFB86FA344BFBF2D6802E60286C9C8C7@SHSMSX101.ccr.corp.intel.com> References: <1417329845-7482-1-git-send-email-michael.qiu@intel.com> <1417594223-2573-1-git-send-email-michael.qiu@intel.com> <20141203154029.GA6340@bricha3-MOBL3> 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 02:51:24 -0000 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-limits= ]=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. C= hanging=0A= > it to 1UL << 34 will keep all entries consistent.=0A= =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= =0A= Thanks,=0A= Michael=0A= >=0A= =0A=