From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from youngberry.canonical.com (youngberry.canonical.com [91.189.89.112]) by dpdk.org (Postfix) with ESMTP id 2C7E2F11 for ; Wed, 29 Aug 2018 10:27:32 +0200 (CEST) Received: from mail-oi0-f70.google.com ([209.85.218.70]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1fuvp5-0006ow-Jf for dev@dpdk.org; Wed, 29 Aug 2018 08:27:31 +0000 Received: by mail-oi0-f70.google.com with SMTP id q11-v6so3589944oih.15 for ; Wed, 29 Aug 2018 01:27:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Xc6Opp4mhKMQnXngjJgEZWL+nI/sycWwQyiIPZqwWUQ=; b=C0bc5+qYORb79ZUd4GxyZ28upk87yYhMUAAWGEkp9/bUK5eKfiRxtQicAoWrDXwkVZ oN6u7Q0KEoJ3FCMCYwjzBkkDePw0IB87GIzaDaS7HtTEF2lQqtAPshvSwCFZdnv8v/Js mgf+WhjZQi6ZbvOKAQS6RaYuTuU8dxy7hTV7lnpafafcFuJlF9BXHvV2YeoXACGMehSl IFGUaD8DZTiJMle5Pf5/aSpCNiwD2dpGOMOY0sfQfD+DogQ+8whpPC1AqQAzKPBtRHLd R7+5N2vBRtI0+Gu7vfLnBbScAU/2MHyB0YFpjjm/GAEmRfvz1PIXAv5EiCPhJe7exa0D eulw== X-Gm-Message-State: APzg51DrA0x3/Quc3QJfkLumUHNH+AJ3K3d/i7qtkxA/OB4SlAedNBK2 BvwH4EhRW71chll/gFk49sCrvw7Q6aWJWx8s/QNqW/ebxSXxgmA61IALAl/pkzelfJXDVHjhlfs GMSswbfirDJD7stM0jjPn58fsCIdLAOBGU04i X-Received: by 2002:aca:6044:: with SMTP id u65-v6mr1750017oib.323.1535531250467; Wed, 29 Aug 2018 01:27:30 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYAIyEoyD08fy7kPLmJ9eFgVgyw1+Eabe+UoOM6cvQW9OcZE5dA00V6NnmSvM4+d9uPJ5LnXqJQTW2/AIRANLQ= X-Received: by 2002:aca:6044:: with SMTP id u65-v6mr1749997oib.323.1535531250003; Wed, 29 Aug 2018 01:27:30 -0700 (PDT) MIME-Version: 1.0 References: <20180827122219.GB3695@6wind.com> <20180828114422.GG3695@6wind.com> <20180828150235.GH3695@6wind.com> In-Reply-To: <20180828150235.GH3695@6wind.com> From: Christian Ehrhardt Date: Wed, 29 Aug 2018 10:27:03 +0200 Message-ID: To: adrien.mazarguil@6wind.com Cc: dev , Gowrishankar Muthukrishnan , Chao Zhu , Luca Boccassi , Thomas Monjalon Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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: Wed, 29 Aug 2018 08:27:32 -0000 On Tue, Aug 28, 2018 at 5:02 PM Adrien Mazarguil wrote: > On Tue, Aug 28, 2018 at 02:38:35PM +0200, Christian Ehrhardt wrote: > > On Tue, Aug 28, 2018 at 1:44 PM Adrien Mazarguil < > adrien.mazarguil@6wind.com> > > wrote: > > > > > On Tue, Aug 28, 2018 at 01:30:12PM +0200, Christian Ehrhardt wrote: > > > > On Mon, Aug 27, 2018 at 2:22 PM Adrien Mazarguil < > > > adrien.mazarguil@6wind.com> > > > > wrote: > > > > > > > > > Hi Christian, > > > > > > > > > > On Wed, Aug 22, 2018 at 05:11:41PM +0200, Christian Ehrhardt wrot= e: > > > > > > 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 m= e > > > that my > > > > > > change is better than a band aid). > > > > > > > > > > Thanks for reporting. I've made a quick investigation on my own a= nd > > > believe > > > > > it's a toolchain issue which may affect more than this PMD; > > > potentially all > > > > > users of stdbool.h (C11) on this platform. > > > > > > > > > > > > > Yeah I assumed as much, which is why I was hoping that some of the > arch > > > > experts would jump in and say "yeah this is a common thing and > correctly > > > > handled like " > > > > I'll continue trying to reach out to people that should know better > still > > > > ... > > > > > > > > > > > > > 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, henc= e > 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 n= ot > > > 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. > > > > > > > > > > > > > The undef of a definition in header A by hedaer B can lead to most > > > > interesting, still broken effects. > > > > If e.g. one does > > > > #include > > > > #include "mlx5.h" > > > > > > > > or similar then it would undefine that of stdbool as well right? > > > > In any case, the undefine not only would be suspicious it also fail= s > > > right > > > > away: > > > > > > > > In file included from > > > > /home/ubuntu/deb_dpdk/lib/librte_eal/common/malloc_heap.c:27: > > > > /home/ubuntu/deb_dpdk/lib/librte_eal/common/eal_memalloc.h:30:15: > > > > error: unknown > > > > type name =E2=80=98bool=E2=80=99; did you mean =E2=80=98_Bool=E2=80= =99? > > > > int socket, bool exact); > > > > ^~~~ > > > > _Bool > > > > [...] > > > > > > > > > > > > > > > > > Ditto for "pixel" and "vector" keywords. Alternatively you cou= ld > > > #define > > > > > __APPLE_ALTIVEC__ before including altivec.h to prevent them > from > > > > > getting > > > > > defined in the first place. > > > > > > > > > > > > > Interesting I got plenty of these: > > > > In file included from > > > > /home/ubuntu/deb_dpdk/lib/librte_eal/common/eal_common_options.c:25= : > > > > > /home/ubuntu/deb_dpdk/debian/build/static-root/include/rte_memcpy.h:39: > > > > warning: > > > > "__APPLE_ALTIVEC__" redefined > > > > #define __APPLE_ALTIVEC__ > > > > > > > > With a few of it being even errors, but the position of the origina= l > > > define > > > > is interesting. > > > > > /home/ubuntu/deb_dpdk/debian/build/static-root/include/rte_memcpy.h:39: > > > error: > > > > "__APPLE_ALTIVEC__" redefined [-Werror] > > > > #define __APPLE_ALTIVEC__ > > > > : note: this is the location of the previous definition > > > > > > > > So if being a built-in, shouldn't it ALWAYS be defined and never > > > > over-declare the bool type? > > > > > > > > Checking GCC on the platform: > > > > $ gcc -dM -E - < /dev/null | grep ALTI > > > > #define __ALTIVEC__ 1 > > > > #define __APPLE_ALTIVEC__ 1 > > > > > > > > > > > > I added an #error in the header and dropped all dpdk changes. > > > > if !defined(__APPLE_ALTIVEC__) > > > > /* You are allowed to undef these for C++ compatibility. */ > > > > #error WOULD REDECLARE BOOL > > > > #define vector __vector > > > > > > > > And I get: > > > > gcc -Wp,-MD,./.mlx4.o.d.tmp -Wdate-time -D_FORTIFY_SOURCE=3D2 -m64 > -pthread > > > > -DRTE_MACHINE_CPUFLAG_PPC64 -DRTE_MACHINE_CPUFLAG_ALTIVEC > > > > -DRTE_MACHINE_CPUFLAG_VSX -I/home/ubuntu/deb_dpdk/debia > > > > n/build/static-root/include -include > > > > /home/ubuntu/deb_dpdk/debian/build/static-root/include/rte_config.h > -O3 > > > > -std=3Dc11 -Wall -Wextra -g -I. -D_BSD_SOURCE -D_DEFAULT_SOURCE > > > > -D_XOPEN_SOURCE=3D600 > > > > -W -Wall -Wstrict-prototypes -Wmissing-prototypes > -Wmissing-declarations > > > > -Wold-style-definition -Wpointer-arith -Wcast-align -Wnested-extern= s > > > > -Wcast-qual -Wformat-nonliteral -Wformat-securi > > > > ty -Wundef -Wwrite-strings -Wdeprecated -Wimplicit-fallthrough=3D2 > > > > -Wno-format-truncation -DALLOW_EXPERIMENTAL_API -Wno-error=3Dcast-q= ual > > > > -DNDEBUG -UPEDANTIC -g -g -o mlx4.o -c /home/ubuntu/de > > > > b_dpdk/drivers/net/mlx4/mlx4.c > > > > In file included from > > > > > /home/ubuntu/deb_dpdk/debian/build/static-root/include/rte_memcpy.h:39, > > > > from > > > > > /home/ubuntu/deb_dpdk/debian/build/static-root/include/rte_ether.h:21, > > > > from > > > > > /home/ubuntu/deb_dpdk/debian/build/static-root/include/rte_ethdev.h:158, > > > > from > > > > > > > > /home/ubuntu/deb_dpdk/debian/build/static-root/include/rte_ethdev_driver.= h:18, > > > > > > > > from > /home/ubuntu/deb_dpdk/drivers/net/mlx4/mlx4.c:35: > > > > /usr/lib/gcc/powerpc64le-linux-gnu/8/include/altivec.h:44:2: error: > > > #error > > > > WOULD REDECLARE BOOL > > > > #error WOULD REDECLARE BOOL > > > > > > > > But a quick sanity test with a hello world including this special > altivec > > > > header did build not reaching the #error. > > > > So something in DPDK undefines __ALTIVEC__ ?! > > > > > > > > After being that close I found which of our usual build does the > switch > > > to > > > > trigger this. > > > > It is "-std=3Dc11" > > > > > > > > And in fact > > > > $ gcc -std=3Dc11 -dM -E - < /dev/null | grep ALTI > > > > #define __ALTIVEC__ 1 > > > > > > > > But no __APPLE_ALTIVEC__ > > > > > > > > The header says > > > > /* You are allowed to undef these for C++ compatibility. */ > > > > > > > > But I thought "wait a minute, didn't we just undefine it above and = it > > > > failed?" > > > > Yes we did, and it turns out not all gcc calls have --std=3Dc11 and > due to > > > > that it failed for those. > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > I tested a few versions of this after my findings on #1 above. > > > > A few extra loops to jump like to make > drivers/net/cxgbe/cxgbe_compat.h > > > > usage of bool happy. > > > > I eventually came up with the following as a fix that seems to work= : > > > > > > > > --- a/lib/librte_eal/common/include/arch/ppc_64/rte_memcpy.h > > > > +++ b/lib/librte_eal/common/include/arch/ppc_64/rte_memcpy.h > > > > @@ -37,6 +37,19 @@ > > > > #include > > > > /*To include altivec.h, GCC version must >=3D 4.8 */ > > > > #include > > > > +/* > > > > + * if built with std=3Dc11 stdbool and vector bool will conflict. > > > > + * But if std is not c11 (which is true for some of our gcc calls) > it > > > will > > > > + * have __APPLE_ALTIVEC__ defined which will make it not define th= e > > > types > > > > + * at all. > > > > + * Furthermore we need to be careful to only redefine as stdbool > would > > > have > > > > + * done if it was included - otherwise we might conflict with othe= r > > > > intended > > > > + * meanings of "bool". > > > > + */ > > > > +#if defined(__STDC_VERSION__) && __STDC_VERSION__ >=3D 201112L && > > > > defined(_STDBOOL_H) > > > > +#undef bool > > > > +#define bool _Bool > > > > +#endif > > > > > > > > #ifdef __cplusplus > > > > extern "C" { > > > > > > > > > > > > In turn I have only checked this modification on ppc64 so far, but > > > anyway I > > > > still have the feeling we are only trying to poke at things with a > stick > > > > and someone with subject matter experience would just tell us. > > > > Opinions on the change above as a "v2 RFC"? > > > > > > Thanks for the detailed analysis :) > > > > > > I'm afraid this suggestion can still break since stdbool.h won't be > > > necessarily included before altivec.h. How about this instead? > > > > > > /* Blurb */ > > > #ifndef __APPLE_ALTIVEC__ > > > #define __APPLE_ALTIVEC__ 1 > > > #endif > > > #include > > > > > > > I was there before in my experiments - even a bit safer with the > following > > to only do so in C11 mode to avoid cases where one might have "undefine= d" > > it in non C11 for a reason so we do not switch it on again unexpectedly= . > > > > --- a/lib/librte_eal/common/include/arch/ppc_64/rte_memcpy.h > > +++ b/lib/librte_eal/common/include/arch/ppc_64/rte_memcpy.h > > @@ -36,6 +36,14 @@ > > #include > > #include > > /*To include altivec.h, GCC version must >=3D 4.8 */ > > +/* > > + * If built with std=3Dc11 stdbool and altivec bool will conflict. > > + * The altivec bool type is not needed at the moment, to avoid the > conflict > > + * define __APPLE_ALTIVEC__ so that the conflict will not happen. > > + */ > > +#if defined(__STDC_VERSION__) && __STDC_VERSION__ >=3D 201112L && > > !defined(__APPLE_ALTIVEC__) > > +#define __APPLE_ALTIVEC__ > > +#endif > > #include > > > > #ifdef __cplusplus > > > > But it turned out we are not allowed to switch of other things as vecto= r > > (and probably some more code than the type) is actually used: > > With your suggestion or mine above it will break on: > > > > x5.o -c /home/ubuntu/deb_dpdk/drivers/net/mlx5/mlx5.c > > In file included from > /home/ubuntu/deb_dpdk/drivers/net/mlx5/mlx5_prm.h:21, > > from > /home/ubuntu/deb_dpdk/drivers/net/mlx5/mlx5_rxtx.h:37, > > from /home/ubuntu/deb_dpdk/drivers/net/mlx5/mlx5.h:36, > > from /home/ubuntu/deb_dpdk/drivers/net/mlx5/mlx5.c:42: > > /home/ubuntu/deb_dpdk/debian/build/static-root/include/rte_vect.h:43:15= : > error: > > expected =E2=80=98;=E2=80=99 before =E2=80=98signed=E2=80=99 > > typedef vector signed int xmm_t; > > ^~~~~~~ > > ; > > /home/ubuntu/deb_dpdk/debian/build/static-root/include/rte_vect.h:49:2: > error: > > expected specifier-qualifier-list before =E2=80=98xmm_t=E2=80=99 > > xmm_t x; > > ^~~~~ > > > > I have no much better suggestion for the ordering issue that you raised= . > > To test what would happen I moved the stdbool include after all other > > includes in drivers/net/mlx5/mlx5_nl.c > > I also moved mlx5.h (which eventually brings in altivec) right at the > top. > > This works to build, but such a check is always subtle as one of the > other > > includes might have pulled in stdbool before altivec still. > > For a bit of confidence I picked said gcc call and ran it with -E. > > The output suggests altivec really was included before stdbool. > > How about making altivec.h users (rte_vect.h and rte_memcpy.h) rely on > "__vector" directly instead of the "vector" macro to make it transparent > for > others then? > > I think we can assume they have internal knowledge of this file in order = to > deal with __APPLE_ALTIVEC__ anyway. > While "pushing the internal knowledge out to users" sounds right at first. There are far too many IMHO, the change would be huge unclean and messy. $ grep -Hrn altivec.h drivers/net/i40e/i40e_rxtx_vec_altivec.c:45:#include examples/l3fwd/l3fwd_lpm.c:165:#include "l3fwd_lpm_altivec.h" examples/l3fwd/l3fwd_lpm_altivec.h:10:#include "l3fwd_altivec.h" MAINTAINERS:239:F: examples/l3fwd/*altivec.h lib/librte_acl/acl_run_altivec.c:34:#include "acl_run_altivec.h" lib/librte_eal/common/include/arch/ppc_64/rte_memcpy.h:49:/*To include altivec.h, GCC version must >=3D 4.8 */ lib/librte_eal/common/include/arch/ppc_64/rte_memcpy.h:50:#include < altivec.h> lib/librte_eal/common/include/arch/ppc_64/rte_vect.h:36:#include lib/librte_lpm/meson.build:9:headers +=3D files('rte_lpm_altivec.h', 'rte_lpm_neon.h', 'rte_lpm_sse.h') lib/librte_lpm/Makefile:28:SYMLINK-$(CONFIG_RTE_LIBRTE_LPM)-include +=3D rte_lpm_altivec.h lib/librte_lpm/rte_lpm.h:461:#include "rte_lpm_altivec.h" > Also I would suggest not to make this workaround C11-only. I suspect the > same issue will be encountered with -std=3Dc99 or -std=3Dc90. Keep in min= d DPDK > applications are free to specify their own CFLAGS. > Yeah Independent to the other part of the discussion I think we can make it generally apply and not just C11. The following "would work" in the code right now. --- a/lib/librte_eal/common/include/arch/ppc_64/rte_memcpy.h +++ b/lib/librte_eal/common/include/arch/ppc_64/rte_memcpy.h @@ -35,6 +35,21 @@ #include #include +/* + * if built with newer C standard like -std=3Dc11 stdbool.h bool and altiv= ec + * bool types will conflict. We have to force altivec users (rte_vect.h an= d + * rte_memcpy.h) rely on __vector implying internal altivec knowledge to the + * users but keeping things transparent for all others. + * Therefore define __APPLE_ALTIVEC__ which make it not (re-)define the + * non prefixed types lile "bool". + * While we need to disambiguise bool, we want vector/pixel to stay as-is + * in those cases so define them as altivec.h would. + */ +#ifndef __APPLE_ALTIVEC__ +#define __APPLE_ALTIVEC__ 1 +#define vector __vector +#define pixel __pixel +#endif /*To include altivec.h, GCC version must >=3D 4.8 */ #include But here again, ordering could make altivec.h be included before this statement in rte_memcpy. I would not want to see us search and replace all occurrence of "vector" nor doing the same trick all over the place at every include of altivec.h How about the following which should address the follwing: - resolve the issue with stbool conflicting - no issues with vector types as it retains what would be defined - have the workaround in just one place - independent to include order as long as rte_altivec.h is uses instead of a direct include diff --git a/drivers/net/i40e/i40e_rxtx_vec_altivec.c b/drivers/net/i40e/i40e_rxtx_vec_altivec.c index f3fc8267..31dc6839 100644 --- a/drivers/net/i40e/i40e_rxtx_vec_altivec.c +++ b/drivers/net/i40e/i40e_rxtx_vec_altivec.c @@ -42,7 +42,7 @@ #include "i40e_rxtx.h" #include "i40e_rxtx_vec_common.h" -#include +#include #pragma GCC diagnostic ignored "-Wcast-qual" diff --git a/lib/librte_eal/common/Makefile b/lib/librte_eal/common/Makefil= e index cca68826..cab13f1d 100644 --- a/lib/librte_eal/common/Makefile +++ b/lib/librte_eal/common/Makefile @@ -17,6 +17,7 @@ INC +=3D rte_malloc.h rte_keepalive.h rte_time.h INC +=3D rte_service.h rte_service_component.h INC +=3D rte_bitmap.h rte_vfio.h rte_hypervisor.h rte_test.h INC +=3D rte_reciprocal.h rte_fbarray.h rte_uuid.h +INC +=3D rte_altivec.h GENERIC_INC :=3D rte_atomic.h rte_byteorder.h rte_cycles.h rte_prefetch.h GENERIC_INC +=3D rte_spinlock.h rte_memcpy.h rte_cpuflags.h rte_rwlock.h diff --git a/lib/librte_eal/common/include/arch/ppc_64/rte_memcpy.h b/lib/librte_eal/common/include/arch/ppc_64/rte_memcpy.h index 75f74897..225de7a0 100644 --- a/lib/librte_eal/common/include/arch/ppc_64/rte_memcpy.h +++ b/lib/librte_eal/common/include/arch/ppc_64/rte_memcpy.h @@ -35,8 +35,8 @@ #include #include -/*To include altivec.h, GCC version must >=3D 4.8 */ -#include + +#include #ifdef __cplusplus extern "C" { diff --git a/lib/librte_eal/common/include/arch/ppc_64/rte_vect.h b/lib/librte_eal/common/include/arch/ppc_64/rte_vect.h index 99586e58..1ac81d73 100644 --- a/lib/librte_eal/common/include/arch/ppc_64/rte_vect.h +++ b/lib/librte_eal/common/include/arch/ppc_64/rte_vect.h @@ -33,7 +33,7 @@ #ifndef _RTE_VECT_PPC_64_H_ #define _RTE_VECT_PPC_64_H_ -#include +#include #include "generic/rte_vect.h" #ifdef __cplusplus diff --git a/lib/librte_eal/common/include/rte_altivec.h b/lib/librte_eal/common/include/rte_altivec.h new file mode 100644 index 00000000..e620e701 --- /dev/null +++ b/lib/librte_eal/common/include/rte_altivec.h @@ -0,0 +1,60 @@ +/*- + * BSD LICENSE + * + * Copyright 2018 Canonical Ltd. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * * Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * * Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in + * the documentation and/or other materials provided with the + * distribution. + * * Neither the name of NXP nor the names of its + * contributors may be used to endorse or promote products derived + * from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + + +#ifndef _RTE_EAL_ALTIVEC_H_ +#define _RTE_EAL_ALTIVEC_H_ + +/* + * if built with newer C standard like -std=3Dc11 stdbool.h bool and altiv= ec + * bool types will conflict. + * There is no user of the altivec bool type, so make sure it never is + * defined. Therefore define __APPLE_ALTIVEC__ which make it not (re-)define + * the non prefixed types lile "bool". + * On the other hand other types like vector are used, so while we need to + * disambiguise type bool, we want vector/pixel to stay as-is so we define + * them as altivec.h would. + * Note: without -std=3D the compiler has all those as context sensitive + * keywords and the header will not define them at all. Therefore the + * compiler has __APPLE_ALTIVEC__ already set in those cases - therefore w= e + * don't touch things if __APPLE_ALTIVEC__ is already set. + */ +#ifndef __APPLE_ALTIVEC__ +#define __APPLE_ALTIVEC__ 1 +#define vector __vector +#define pixel __pixel +#endif + +/*To include altivec.h, GCC version must >=3D 4.8 */ +#include + +#endif /* _RTE_EAL_ALTIVEC_H_ */ diff --git a/lib/librte_eal/common/meson.build b/lib/librte_eal/common/meson.build index 56005bea..616f2084 100644 --- a/lib/librte_eal/common/meson.build +++ b/lib/librte_eal/common/meson.build @@ -45,6 +45,7 @@ common_objs +=3D eal_common_arch_objs common_headers =3D files( 'include/rte_alarm.h', + 'include/rte_altivec.h', 'include/rte_branch_prediction.h', 'include/rte_bus.h', 'include/rte_bitmap.h', > $ grep -e 'stdbool.h' -e 'altivec.h' mlx5_nl.E > > # 1 "/usr/lib/gcc/powerpc64le-linux-gnu/8/include/altivec.h" 1 3 4 > > # 1 "/usr/lib/gcc/powerpc64le-linux-gnu/8/include/stdbool.h" 1 3 4 > > > > Still the build worked with the fix as suggested in my last mail: > > --- a/lib/librte_eal/common/include/arch/ppc_64/rte_memcpy.h > > +++ b/lib/librte_eal/common/include/arch/ppc_64/rte_memcpy.h > > @@ -37,6 +37,19 @@ > > #include > > /*To include altivec.h, GCC version must >=3D 4.8 */ > > #include > > +/* > > + * if built with std=3Dc11 stdbool and vector bool will conflict. > > + * But if std is not c11 (which is true for some of our gcc calls) it > will > > + * have __APPLE_ALTIVEC__ defined which will make it not define the > types > > + * at all. > > + * Furthermore we need to be careful to only redefine as stdbool would > have > > + * done if it was included - otherwise we might conflict with other > > intended > > + * meanings of "bool". > > + */ > > +#if defined(__STDC_VERSION__) && __STDC_VERSION__ >=3D 201112L && > > defined(_STDBOOL_H) > > +#undef bool > > +#define bool _Bool > > +#endif > > > > #ifdef __cplusplus > > extern "C" { > > > > Which is odd, as I'd have expected the stdbool.h inclusion would then > > trigger a redefinition of the bool type. > > Yeah, seems like internal GCC headers in /usr/lib are exempt from warning= s > on conflicting definitions or some such. > > -- > Adrien Mazarguil > 6WIND > --=20 Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd