From patchwork Thu Aug 30 11:55:04 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Christian Ehrhardt X-Patchwork-Id: 44018 X-Patchwork-Delegate: thomas@monjalon.net Return-Path: X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 541EB2BF7; Thu, 30 Aug 2018 13:55:09 +0200 (CEST) Received: from youngberry.canonical.com (youngberry.canonical.com [91.189.89.112]) by dpdk.org (Postfix) with ESMTP id 7CB112BA3 for ; Thu, 30 Aug 2018 13:55:07 +0200 (CEST) Received: from 1.general.paelzer.uk.vpn ([10.172.196.172] helo=lap.fritz.box) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1fvLXX-0005sB-1D; Thu, 30 Aug 2018 11:55:07 +0000 From: Christian Ehrhardt To: adrien.mazarguil@6wind.com, dev , Gowrishankar Muthukrishnan , Chao Zhu Cc: Luca Boccassi , Thomas Monjalon , Christian Ehrhardt Date: Thu, 30 Aug 2018 13:55:04 +0200 Message-Id: <20180830115504.28608-1-christian.ehrhardt@canonical.com> X-Mailer: git-send-email 2.17.1 MIME-Version: 1.0 Subject: [dpdk-dev] [PATCH v2] ppc64: fix compilation of when AltiVec is enabled 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" The definition of almost any newer standard like --stc=c11 will drop __APPLCE_ALTIVEC__ which otherwise would be defined. If that is the case then altivec.h will redefine bool to a type conflicting with those defined by stdbool.h. This breaks compilation of 18.08 on ppc64 like: mlx5_nl_flow.c:407:17: error: incompatible types when assigning to type ‘__vector __bool int’ {aka ‘__vector(4) __bool int’} from type ‘int’ in_port_id_set = false; Other alternatives were pursued on [1] but they always ended up being more complex than what would be appropriate for the issue we face. [1]: http://mails.dpdk.org/archives/dev/2018-August/109926.html Tested-by: Takeshi T Yoshimura Reviewed-by: Adrien Mazarguil adrien.mazarguil@6wind.com Signed-off-by: Christian Ehrhardt --- .../common/include/arch/ppc_64/rte_memcpy.h | 11 +++++++++++ 1 file changed, 11 insertions(+) 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 75f74897b..0b3b89b56 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 @@ -37,6 +37,17 @@ #include /*To include altivec.h, GCC version must >= 4.8 */ #include +/* + * Compilation workaround for PPC64 targets when AltiVec is fully + * enabled e.g. with std=c11. Otherwise there would be a type conflict + * of "bool" between stdbool and altivec. + */ +#if defined(__PPC64__) && !defined(__APPLE_ALTIVEC__) + #undef bool + /* redefine as in stdbool.h */ + #define bool _Bool +#endif + #ifdef __cplusplus extern "C" {