From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id DA4657DF0 for ; Fri, 19 Dec 2014 19:01:09 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 19 Dec 2014 10:00:39 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,607,1413270000"; d="scan'208";a="650590323" Received: from bricha3-mobl3.ger.corp.intel.com ([10.243.20.27]) by fmsmga002.fm.intel.com with SMTP; 19 Dec 2014 10:00:33 -0800 Received: by (sSMTP sendmail emulation); Fri, 19 Dec 2014 18:00:31 +0025 Date: Fri, 19 Dec 2014 18:00:31 +0000 From: Bruce Richardson To: Olivier Matz Message-ID: <20141219180030.GA1420@bricha3-MOBL3> References: <1418820925-20318-1-git-send-email-olivier.matz@6wind.com> <20141217140826.GE9184@bricha3-MOBL3> <20141217142437.GF9184@bricha3-MOBL3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20141217142437.GF9184@bricha3-MOBL3> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 0/5] fix compilation issues seen with clang-3.5 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: Fri, 19 Dec 2014 18:01:10 -0000 On Wed, Dec 17, 2014 at 02:24:38PM +0000, Bruce Richardson wrote: > On Wed, Dec 17, 2014 at 02:08:27PM +0000, Bruce Richardson wrote: > > On Wed, Dec 17, 2014 at 01:55:20PM +0100, Olivier Matz wrote: > > > This series are compilation fixes seen with clang-3.5 on linux. > > >=20 > > > Olivier Matz (5): > > > test-devargs: fix misplaced braces in strncmp call > > > examples/l3fwd: fix compilation with clang 3.5 > > > examples/netmap: fix overflow in ioctl operation > > > examples/vm_power_manager: move -lvirt in LDLIBS > > > examples/vm_power_manager: fix initialization of cmdline token > > >=20 > > > app/test/test_devargs.c | 2 +- > > > examples/l3fwd/main.c | 4 +++- > > > examples/netmap_compat/lib/compat_netmap.c | 2 +- > > > examples/netmap_compat/lib/compat_netmap.h | 2 +- > > > examples/vm_power_manager/Makefile | 4 +++- > > > examples/vm_power_manager/vm_power_cli.c | 2 +- > > > 6 files changed, 10 insertions(+), 6 deletions(-) > > >=20 > > > --=20 > > > 2.1.3 > > >=20 > >=20 > > Interesting. I've just upgraded to Fedora 21, and I'm getting a lot of = other, > > different errors on compilation using its version of clang (3.4.2). Pat= ches soon > > to follow, but I'm surprised that they don't show up in clang 3.5. Perh= aps they > > are just compiler bugs in the Fedora version. > > Examples of the errors are shown below. > >=20 > > /Bruce > >=20 >=20 > This is the latest compile problem I see on Fedora 21 with clang. Anyone = care > to suggest a suitable fix? >=20 > CC rte_eth_bond_args.o > /home/bruce/dpdk.org/lib/librte_pmd_bond/rte_eth_bond_args.c:237:1201: = fatal error: array index 3 is past the end of the array (which contains 3 e= lements) [-Warray-bounds] > if (__extension__ ({ size_t __s1_len, __s2_len; (__builtin_constant_p = (("l2")) && __builtin_constant_p (value) && (__s1_len =3D strlen (("l2")), = __s2_len =3D strlen (value), (!((size_t)(const void *)((("l2")) + 1) - (siz= e_t)(const void *)(("l2")) =3D=3D 1) || __s1_len >=3D 4) && (!((size_t)(con= st void *)((value) + 1) - (size_t)(const void *)(value) =3D=3D 1) || __s2_l= en >=3D 4)) ? __builtin_strcmp (("l2"), value) : (__builtin_constant_p (("l= 2")) && ((size_t)(const void *)((("l2")) + 1) - (size_t)(const void *)(("l2= ")) =3D=3D 1) && (__s1_len =3D strlen (("l2")), __s1_len < 4) ? (__builtin_= constant_p (value) && ((size_t)(const void *)((value) + 1) - (size_t)(const= void *)(value) =3D=3D 1) ? __builtin_strcmp (("l2"), value) : (__extension= __ ({ const unsigned char *__s2 =3D (const unsigned char *) (const char *) = (value); int __result =3D (((const unsigned char *) (const char *) (("l2"))= )[0] - __s2[0]); if (__s1_len > 0 && __result =3D=3D 0) { __result =3D (((c= onst unsigned char *) (const char *) (("l2")))[1] - __s2[1]); if (__s1_len = > 1 && __result =3D=3D 0) { __result =3D (((const unsigned char *) (const c= har *) (("l2")))[2] - __s2[2]); if (__s1_len > 2 && __result =3D=3D 0) __re= sult =3D (((const unsigned char *) (const char *) (("l2")))[3] - __s2[3]); = } } __result; }))) : (__builtin_constant_p (value) && ((size_t)(const void = *)((value) + 1) - (size_t)(const void *)(value) =3D=3D 1) && (__s2_len =3D = strlen (value), __s2_len < 4) ? (__builtin_constant_p (("l2")) && ((size_t)= (const void *)((("l2")) + 1) - (size_t)(const void *)(("l2")) =3D=3D 1) ? _= _builtin_strcmp (("l2"), value) : (- (__extension__ ({ const unsigned char = *__s2 =3D (const unsigned char *) (const char *) (("l2")); int __result =3D= (((const unsigned char *) (const char *) (value))[0] - __s2[0]); if (__s2_= len > 0 && __result =3D=3D 0) { __result =3D (((const unsigned char *) (con= st char *) (value))[1] - __s2[1]); if (__s2_len > 1 && __result =3D=3D 0) {= __result =3D (((const unsigned char *) (const char *) (value))[2] - __s2[2= ]); if (__s2_len > 2 && __result =3D=3D 0) __result =3D (((const unsigned c= har *) (const char *) (value))[3] - __s2[3]); } } __result; })))) : __built= in_strcmp (("l2"), value)))); }) =3D=3D 0) >=20 > The offending line is the seemingly innoculous: > 237 if (strcmp(PMD_BOND_XMIT_POLICY_LAYER2_KVARG, value) =3D=3D 0) >=20 > where the first parameter is the constant value "12". >=20 > Any thoughts in the community? >=20 > /Bruce Is anyone else seeing issues with clang on Fedora 21? I have tried a number= of systems here, and on two of them (one board upgraded from Fedora 20, and an= other VM freshly installed from an iso image), I get the errors referred to in th= e last two mails on this thread. However, on two other systems (again one upgraded= , one freshly installed), I see no compilation issues at all. It very much looks to me like a clang or system setup issue, rather than a = DPDK one, but I'm just curious if anyone else has seen any problems? /Bruce