From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) by dpdk.org (Postfix) with ESMTP id 0C2854CB1 for ; Mon, 27 Aug 2018 14:22:36 +0200 (CEST) Received: by mail-wr1-f43.google.com with SMTP id z96-v6so13435357wrb.8 for ; Mon, 27 Aug 2018 05:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=VTz+sPocF+QyIfFu3LCDSGemqB6K6umHNWGTmEYjw/I=; b=K8thw3wy3xFOFpNITUKp8CkwvwVzt6Ebzk1WUyV9LOQ1a2CuWkPEQjew2b9aywp5K7 pJEAK1Maxiffv/1SnrzA7zhKTBO+4d4au3n9hUZa9hoLt6oReAGVVbSJIZ34RQ3fl6yD 6d2MNRJUbTD7+gOhQhg+bxx2LhJC2kRQut6E/cgAVaZQZlCQmDDM7Xo3pny+FJlZKXGU QR6QuJdV5QhVk8mFQvys3zHHHBiyY6B0B3WmtreuGRgveIkVdc5TWf8tpksVdYW5QFmI tXgTLr9OuJ1S5v+FPykVgFCkqrmw4FiV2l4JWNB7S39B/gwsS8iBAJuzVKN7KNXLyWDL 5aKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=VTz+sPocF+QyIfFu3LCDSGemqB6K6umHNWGTmEYjw/I=; b=oKOo1XNKzyA5OTEZsw7cs5hq6+Zfc29GhJX8ANygnj1VJqxmrmK14Py7UBmNs17Afj eCwGTvfTDWKdc2yv2fH5oxg4E5g04ueW+VXApWXXV8PKFViDkOIAEXGQpAg5sYqZO+Uw ECXjj2StfVL6TAnnM+cdhMCrwivhb+QDbNzfydImRklTumw6SFbDo2NImVOhMGybXXyL O5kLPGb2k/g563lGMgjVx5fMZ4sSwac72E5BGxkOddaDbaZKXtTUI8pfSUgvq6TQ+QRB fzwT3i4ivkpylYCDcXrlvURkNJuBP6PXCAH1OZO0uJH1lKlDeFHrNZvnWUJPn3EgSnsk 3fWg== X-Gm-Message-State: APzg51ASLZ6Lg2T2bXik3HtPf5dMcIkmWNOr1pMH2XYLlvgtmO1nXXji BsNiM7uno9TXlybOyJs822kx0A== X-Google-Smtp-Source: ANB0VdaWvxiRox/O6ULvorWEtw36TucJtSaKm57JayQ88Y/HjoVB021NPQg05m3ZN1CdFxWTg9YALQ== X-Received: by 2002:a5d:6aca:: with SMTP id u10-v6mr7647898wrw.44.1535372555769; Mon, 27 Aug 2018 05:22:35 -0700 (PDT) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id v46-v6sm21092586wrc.63.2018.08.27.05.22.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Aug 2018 05:22:34 -0700 (PDT) Date: Mon, 27 Aug 2018 14:22:19 +0200 From: Adrien Mazarguil To: Christian Ehrhardt Cc: dev , Gowrishankar Muthukrishnan , Chao Zhu , Luca Boccassi , Thomas Monjalon Message-ID: <20180827122219.GB3695@6wind.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] 18.08 build error on ppc64el - bool as vector type X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2018 12:22:36 -0000 Hi Christian, On Wed, Aug 22, 2018 at 05:11:41PM +0200, Christian Ehrhardt wrote: > Just FYI the simple change hits similar issues later on. > > The (not really) proposed patch would have to be extended to be as > following. > We really need a better solution (or somebody has to convince me that my > change is better than a band aid). Thanks for reporting. I've made a quick investigation on my own and believe it's a toolchain issue which may affect more than this PMD; potentially all users of stdbool.h (C11) on this platform. C11's stdbool.h defines a bool macro as _Bool (big B) along with true/false. On PPC targets, another file (altivec.h) defines bool as _bool (small b) but not true/false: #if !defined(__APPLE_ALTIVEC__) /* You are allowed to undef these for C++ compatibility. */ #define vector __vector #define pixel __pixel #define bool __bool #endif mlx5_nl.c explicitly includes stdbool.h to get the above definitions then includes mlx5.h -> rte_ether.h -> ppc_64/rte_memcpy.h -> altivec.h. For some reason the conflicting bool redefinition doesn't seem to raise any warnings, but results in mismatching bool and true/false definitions; an integer value cannot be assigned to a bool variable anymore, hence the build failure. The inability to assign integer values to bool is, in my opinion, a fundamental issue caused by altivec.h. If there is no way to fix this on the system, there are a couple of workarounds for DPDK, by order of preference: 1. Always #undef bool after including altivec.h in lib/librte_eal/common/include/arch/ppc_64/rte_memcpy.h. I do not think anyone expects this type to be unusable with true/false or integer values anyway. The version of altivec.h I have doesn't rely on this macro at all so it's probably not a big loss. Ditto for "pixel" and "vector" keywords. Alternatively you could #define __APPLE_ALTIVEC__ before including altivec.h to prevent them from getting defined in the first place. 2. Add Altivec detection to impacted users of stdbool.h, which #undef and redefine bool as _Bool on their own with a short comment about broken toolchains. 3. Replace bool with _Bool to impacted users of stdbool.h. Basically what you did below with "int" but slightly more correct since true/false can still be used with _Bool. A comment explaining why is necessary after the inclusion of stdbool.h. Can you validate these suggestions? I don't have the right setup for that. Thanks. > Description: Fix ppc64le build error between altivec and bool > > We really hope there will eventually be a better fix for this, but > currently > we have to unbreak building this code so until something better is > available > let's use this modification. > > Forwarded: yes > Forward-info: http://mails.dpdk.org/archives/dev/2018-August/109926.html > Author: Christian Ehrhardt > Last-Update: 2018-08-22 > --- a/drivers/net/mlx5/mlx5_nl.c > +++ b/drivers/net/mlx5/mlx5_nl.c > @@ -834,8 +834,8 @@ mlx5_nl_switch_info_cb(struct nlmsghdr * > .switch_id = 0, > }; > size_t off = NLMSG_LENGTH(sizeof(struct ifinfomsg)); > - bool port_name_set = false; > - bool switch_id_set = false; > + int port_name_set = 0; > + int switch_id_set = 0; > > if (nh->nlmsg_type != RTM_NEWLINK) > goto error; > @@ -854,7 +854,7 @@ mlx5_nl_switch_info_cb(struct nlmsghdr * > if (errno || > (size_t)(end - (char *)payload) != > strlen(payload)) > goto error; > - port_name_set = true; > + port_name_set = 1; > break; > case IFLA_PHYS_SWITCH_ID: > info.switch_id = 0; > @@ -862,7 +862,7 @@ mlx5_nl_switch_info_cb(struct nlmsghdr * > info.switch_id <<= 8; > info.switch_id |= ((uint8_t *)payload)[i]; > } > - switch_id_set = true; > + switch_id_set = 1; > break; > } > off += RTA_ALIGN(ra->rta_len); > --- a/drivers/net/mlx5/mlx5_ethdev.c > +++ b/drivers/net/mlx5/mlx5_ethdev.c > @@ -1335,8 +1335,8 @@ mlx5_sysfs_switch_info(unsigned int ifin > char ifname[IF_NAMESIZE]; > FILE *file; > struct mlx5_switch_info data = { .master = 0, }; > - bool port_name_set = false; > - bool port_switch_id_set = false; > + int port_name_set = 0; > + int port_switch_id_set = 0; > char c; > > if (!if_indextoname(ifindex, ifname)) { > --- a/drivers/net/mlx5/mlx5_nl_flow.c > +++ b/drivers/net/mlx5/mlx5_nl_flow.c > @@ -385,11 +385,11 @@ mlx5_nl_flow_transpose(void *buf, > const struct rte_flow_action *action; > unsigned int n; > uint32_t act_index_cur; > - bool in_port_id_set; > - bool eth_type_set; > - bool vlan_present; > - bool vlan_eth_type_set; > - bool ip_proto_set; > + int in_port_id_set; > + int eth_type_set; > + int vlan_present; > + int vlan_eth_type_set; > + int ip_proto_set; > struct nlattr *na_flower; > struct nlattr *na_flower_act; > struct nlattr *na_vlan_id; > @@ -404,11 +404,11 @@ init: > action = actions; > n = 0; > act_index_cur = 0; > - in_port_id_set = false; > - eth_type_set = false; > - vlan_present = false; > - vlan_eth_type_set = false; > - ip_proto_set = false; > + in_port_id_set = 0; > + eth_type_set = 0; > + vlan_present = 0; > + vlan_eth_type_set = 0; > + ip_proto_set = 0; > na_flower = NULL; > na_flower_act = NULL; > na_vlan_id = NULL; > > > On Tue, Aug 21, 2018 at 4:19 PM Christian Ehrhardt < > christian.ehrhardt@canonical.com> wrote: > > > Hi, > > Debian and Ubuntu face a build error with 18.08 on ppc64el. > > It looks like that: > > > > Full log: > > > > https://buildd.debian.org/status/fetch.php?pkg=dpdk&arch=ppc64el&ver=18.08-1&stamp=1534520196&raw=0 > > > > /<>/drivers/net/mlx5/mlx5_nl.c: In function > > 'mlx5_nl_switch_info_cb': > > /<>/drivers/net/mlx5/mlx5_nl.c:837:23: error: incompatible > > types when initializing type '__vector __bool int' {aka '__vector(4) __bool > > int'} using type 'int' > > bool port_name_set = false; > > ^~~~~ > > /<>/drivers/net/mlx5/mlx5_nl.c:838:23: error: incompatible > > types when initializing type '__vector __bool int' {aka '__vector(4) __bool > > int'} using type 'int' > > bool switch_id_set = false; > > ^~~~~ > > /<>/drivers/net/mlx5/mlx5_nl.c:857:18: error: incompatible > > types when assigning to type '__vector __bool int' {aka '__vector(4) __bool > > int'} from type 'int' > > port_name_set = true; > > ^ > > /<>/drivers/net/mlx5/mlx5_nl.c:865:18: error: incompatible > > types when assigning to type '__vector __bool int' {aka '__vector(4) __bool > > int'} from type 'int' > > switch_id_set = true; > > ^ > > /<>/drivers/net/mlx5/mlx5_nl.c:870:16: error: used vector > > type where scalar is required > > info.master = switch_id_set && !port_name_set; > > ^~~~~~~~~~~~~ > > /<>/drivers/net/mlx5/mlx5_nl.c:870:33: error: wrong type > > argument to unary exclamation mark > > info.master = switch_id_set && !port_name_set; > > ^ > > /<>/drivers/net/mlx5/mlx5_nl.c:871:21: error: used vector > > type where scalar is required > > info.representor = switch_id_set && port_name_set; > > > > > > Now I checked and the reason seems to be some combination of altivec and > > MLX headers and the use of bool - probably stdbool vs altivec bool. > > > > If built with gcc -E I see it the bool variables become: > > __attribute__((altivec(bool__))) unsigned port_name_set = > > > > I have found a strawmans approach to it, but I'm sure people with > > experience on the matter will come up with something better. > > > > My current change looks like that and would work: > > $ git diff > > diff --git a/drivers/net/mlx5/mlx5_nl.c b/drivers/net/mlx5/mlx5_nl.c > > index d61826aea..2cc8f49c5 100644 > > --- a/drivers/net/mlx5/mlx5_nl.c > > +++ b/drivers/net/mlx5/mlx5_nl.c > > @@ -834,8 +834,8 @@ mlx5_nl_switch_info_cb(struct nlmsghdr *nh, void > > *arg) > > .switch_id = 0, > > }; > > size_t off = NLMSG_LENGTH(sizeof(struct ifinfomsg)); > > - bool port_name_set = false; > > - bool switch_id_set = false; > > + int port_name_set = 0; > > + int switch_id_set = 0; > > > > if (nh->nlmsg_type != RTM_NEWLINK) > > goto error; > > @@ -854,7 +854,7 @@ mlx5_nl_switch_info_cb(struct nlmsghdr *nh, void > > *arg) > > if (errno || > > (size_t)(end - (char *)payload) != > > strlen(payload)) > > goto error; > > - port_name_set = true; > > + port_name_set = 1; > > break; > > case IFLA_PHYS_SWITCH_ID: > > info.switch_id = 0; > > @@ -862,7 +862,7 @@ mlx5_nl_switch_info_cb(struct nlmsghdr *nh, void > > *arg) > > info.switch_id <<= 8; > > info.switch_id |= ((uint8_t *)payload)[i]; > > } > > - switch_id_set = true; > > + switch_id_set = 1; > > break; > > } > > off += RTA_ALIGN(ra->rta_len); -- Adrien Mazarguil 6WIND