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 A6A42282 for ; Wed, 10 Dec 2014 10:27:02 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 10 Dec 2014 01:26:33 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,551,1413270000"; d="scan'208";a="645344320" Received: from pgsmsx106.gar.corp.intel.com ([10.221.44.98]) by fmsmga002.fm.intel.com with ESMTP; 10 Dec 2014 01:26:32 -0800 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by pgsmsx106.gar.corp.intel.com (10.221.44.98) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 10 Dec 2014 17:26:31 +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; Wed, 10 Dec 2014 17:26:30 +0800 From: "Qiu, Michael" To: "dev@dpdk.org" Thread-Topic: [dpdk-dev] error: value computed is not used Thread-Index: AdASxiisLi704rCnRgagZfyMuDIXlQ== Date: Wed, 10 Dec 2014 09:26:30 +0000 Message-ID: <533710CFB86FA344BFBF2D6802E60286C9E6D1@SHSMSX101.ccr.corp.intel.com> References: <533710CFB86FA344BFBF2D6802E60286C9D989@SHSMSX101.ccr.corp.intel.com> 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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] error: value computed is not used 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: Wed, 10 Dec 2014 09:27:03 -0000 Hi all,=0A= =0A= Any idea?=0A= =0A= Leave this issue in DPDK?=0A= =0A= Thanks,=0A= Michael=0A= On 12/8/2014 5:07 PM, Qiu, Michael wrote:=0A= > Hi all,=0A= > My platform is:=0A= >=0A= > uname -a=0A= > Linux suse-11-sp3 3.0.77-0.11-xen #1 SMP Tue Mar 11 16:48:56 CST 2014=0A= > x86_64 x86_64 x86_64 GNU/Linux=0A= >=0A= > gcc -v=0A= > Using built-in specs.=0A= > COLLECT_GCC=3Dgcc=0A= > COLLECT_LTO_WRAPPER=3D/usr/lib64/gcc/x86_64-suse-linux/4.5/lto-wrapper=0A= > Target: x86_64-suse-linux=0A= > Configured with: ../configure --prefix=3D/usr --infodir=3D/usr/share/info= =0A= > --mandir=3D/usr/share/man --libdir=3D/usr/lib64 --libexecdir=3D/usr/lib64= =0A= > --enable-languages=3Dc,c++,objc,fortran,obj-c++,java,ada=0A= > --enable-checking=3Drelease --with-gxx-include-dir=3D/usr/include/c++/4.5= =0A= > --enable-ssp --disable-libssp --disable-plugin=0A= > --with-bugurl=3Dhttp://bugs.opensuse.org/ --with-pkgversion=3D'SUSE Linux= '=0A= > --disable-libgcj --disable-libmudflap --with-slibdir=3D/lib64=0A= > --with-system-zlib --enable-__cxa_atexit=0A= > --enable-libstdcxx-allocator=3Dnew --disable-libstdcxx-pch=0A= > --enable-version-specific-runtime-libs --program-suffix=3D-4.5=0A= > --enable-linux-futex --without-system-libunwind --enable-gold=0A= > --with-plugin-ld=3D/usr/bin/gold --with-arch-32=3Di586 --with-tune=3Dgene= ric=0A= > --build=3Dx86_64-suse-linux=0A= > Thread model: posix=0A= > gcc version 4.5.1 20101208 [gcc-4_5-branch revision 167585] (SUSE Linux)= =0A= >=0A= > When I try to compile the source code to x86_64 linuxapp, I got this=0A= > error message:=0A= >=0A= > lib/librte_pmd_enic/enic_main.c: In function =91enic_set_rsskey=92:=0A= > lib/librte_pmd_enic/enic_main.c:862:2: error: value computed is not used= =0A= >=0A= > I dig out that, it was ome issue of the macros rte_memcpy()=0A= > #define rte_memcpy(dst, src, n) \=0A= > ((__builtin_constant_p(n)) ? \=0A= > memcpy((dst), (src), (n)) : \=0A= > rte_memcpy_func((dst), (src), (n)))=0A= >=0A= > When I use only (n) instead of (__builtin_constant_p(n), it will pass( I= =0A= > know that it was incorrect, just a experiment).=0A= >=0A= > But I try to use inline function instead of macros:=0A= > static inline void * rte_memcpy(void *dst, const void *src, size_t n)=0A= > {=0A= > return __builtin_constant_p(n) ? memcpy(dst, src, n) :=0A= > rte_memcpy_func(dst, src, n);=0A= > }=0A= >=0A= > It will pass:), and works, this could be one potential workaround fix.=0A= >=0A= > Who knows why? The root cause is what?=0A= >=0A= > I've no idea about this.=0A= >=0A= > Thanks,=0A= > Michael=0A= >=0A= =0A=