From: Bruce Richardson <bruce.richardson@intel.com>
To: Olivier Matz <olivier.matz@6wind.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 0/5] fix compilation issues seen with clang-3.5
Date: Wed, 17 Dec 2014 14:24:38 +0000 [thread overview]
Message-ID: <20141217142437.GF9184@bricha3-MOBL3> (raw)
In-Reply-To: <20141217140826.GE9184@bricha3-MOBL3>
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.
> >
> > 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
> >
> > 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(-)
> >
> > --
> > 2.1.3
> >
>
> 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). Patches soon
> to follow, but I'm surprised that they don't show up in clang 3.5. Perhaps they
> are just compiler bugs in the Fedora version.
> Examples of the errors are shown below.
>
> /Bruce
>
This is the latest compile problem I see on Fedora 21 with clang. Anyone care
to suggest a suitable fix?
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 elements) [-Warray-bounds]
if (__extension__ ({ size_t __s1_len, __s2_len; (__builtin_constant_p (("l2")) && __builtin_constant_p (value) && (__s1_len = strlen (("l2")), __s2_len = strlen (value), (!((size_t)(const void *)((("l2")) + 1) - (size_t)(const void *)(("l2")) == 1) || __s1_len >= 4) && (!((size_t)(const void *)((value) + 1) - (size_t)(const void *)(value) == 1) || __s2_len >= 4)) ? __builtin_strcmp (("l2"), value) : (__builtin_constant_p (("l2")) && ((size_t)(const void *)((("l2")) + 1) - (size_t)(const void *)(("l2")) == 1) && (__s1_len = strlen (("l2")), __s1_len < 4) ? (__builtin_constant_p (value) && ((size_t)(const void *)((value) + 1) - (size_t)(const void *)(value) == 1) ? __builtin_strcmp (("l2"), value) : (__extension__ ({ const unsigned char *__s2 = (const unsigned char *) (const char *) (value); int __result = (((const unsigned char *) (const char *) (("l2")))[0] - __s2[0]); if (__s1_len > 0 && __result == 0) { __result = (((const unsigned char *) (const char *) (("l2")))[1] - __s2[1]); if (__s1_len > 1 && __result == 0) { __result = (((const unsigned char *) (const char *) (("l2")))[2] - __s2[2]); if (__s1_len > 2 && __result == 0) __result = (((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) == 1) && (__s2_len = strlen (value), __s2_len < 4) ? (__builtin_constant_p (("l2")) && ((size_t)(const void *)((("l2")) + 1) - (size_t)(const void *)(("l2")) == 1) ? __builtin_strcmp (("l2"), value) : (- (__extension__ ({ const unsigned char *__s2 = (const unsigned char *) (const char *) (("l2")); int __result = (((const unsigned char *) (const char *) (value))[0] - __s2[0]); if (__s2_len > 0 && __result == 0) { __result = (((const unsigned char *) (const char *) (value))[1] - __s2[1]); if (__s2_len > 1 && __result == 0) { __result = (((const unsigned char *) (const char *) (value))[2] - __s2[2]); if (__s2_len > 2 && __result == 0) __result = (((const unsigned char *) (const char *) (value))[3] - __s2[3]); } } __result; })))) : __builtin_strcmp (("l2"), value)))); }) == 0)
The offending line is the seemingly innoculous:
237 if (strcmp(PMD_BOND_XMIT_POLICY_LAYER2_KVARG, value) == 0)
where the first parameter is the constant value "12".
Any thoughts in the community?
/Bruce
next prev parent reply other threads:[~2014-12-17 14:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-17 12:55 Olivier Matz
2014-12-17 12:55 ` [dpdk-dev] [PATCH 1/5] test-devargs: fix misplaced braces in strncmp call Olivier Matz
2014-12-17 12:55 ` [dpdk-dev] [PATCH 2/5] examples/l3fwd: fix compilation with clang 3.5 Olivier Matz
2014-12-17 12:55 ` [dpdk-dev] [PATCH 3/5] examples/netmap: fix overflow in ioctl operation Olivier Matz
2014-12-17 12:55 ` [dpdk-dev] [PATCH 4/5] examples/vm_power_manager: move -lvirt in LDLIBS Olivier Matz
2014-12-17 12:55 ` [dpdk-dev] [PATCH 5/5] examples/vm_power_manager: fix initialization of cmdline token Olivier Matz
2014-12-17 14:08 ` [dpdk-dev] [PATCH 0/5] fix compilation issues seen with clang-3.5 Bruce Richardson
2014-12-17 14:24 ` Bruce Richardson [this message]
2014-12-19 18:00 ` Bruce Richardson
2014-12-17 23:44 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141217142437.GF9184@bricha3-MOBL3 \
--to=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=olivier.matz@6wind.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).