All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Chao Zhu" <chaozhu@linux.vnet.ibm.com>
To: "'Christian Ehrhardt'" <christian.ehrhardt@canonical.com>,
	<adrien.mazarguil@6wind.com>, "'dev'" <dev@dpdk.org>,
	"'Gowrishankar Muthukrishnan'"
	<gowrishankar.m@linux.vnet.ibm.com>
Cc: "'Luca Boccassi'" <bluca@debian.org>,
	"'Thomas Monjalon'" <thomasm@mellanox.com>
Subject: Re: [PATCH v3] ppc64: fix compilation of when AltiVec is enabled
Date: Fri, 31 Aug 2018 09:48:00 +0800	[thread overview]
Message-ID: <001c01d440cc$a84d20c0$f8e76240$@linux.vnet.ibm.com> (raw)
In-Reply-To: <20180830115959.28935-1-christian.ehrhardt@canonical.com>

I think this patch is good enough to solve the confliction issue.

> -----Original Message-----
> From: Christian Ehrhardt [mailto:christian.ehrhardt@canonical.com]
> Sent: 2018年8月30日 20:00
> To: adrien.mazarguil@6wind.com; dev <dev@dpdk.org>; Gowrishankar
> Muthukrishnan <gowrishankar.m@linux.vnet.ibm.com>; Chao Zhu
> <chaozhu@linux.vnet.ibm.com>
> Cc: Luca Boccassi <bluca@debian.org>; Thomas Monjalon
> <thomasm@mellanox.com>; Christian Ehrhardt
> <christian.ehrhardt@canonical.com>
> Subject: [PATCH v3] ppc64: fix compilation of when AltiVec is enabled
> 
> 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 <TYOS@jp.ibm.com>
> Reviewed-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
> ---
>  .../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 <string.h>
>  /*To include altivec.h, GCC version must  >= 4.8 */  #include <altivec.h>
> +/*
> + * 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" {
> --
> 2.17.1
Acked-by: Chao Zhu <chaozhu@linux.vnet.ibm.com>

  reply	other threads:[~2018-08-31  1:48 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-30 11:59 [PATCH v3] ppc64: fix compilation of when AltiVec is enabled Christian Ehrhardt
2018-08-31  1:48 ` Chao Zhu [this message]
2018-08-31  5:14   ` Christian Ehrhardt
2018-08-31  7:59     ` Chao Zhu
2018-09-03  9:29 ` Adrien Mazarguil
2018-11-05 14:25   ` Thomas Monjalon
2018-11-07 16:00   ` [PATCH] net/mlx5: fix build on PPC64 Thomas Monjalon
2018-11-07 19:05     ` dwilder
2018-11-07 21:10       ` Thomas Monjalon
2018-11-08  8:25         ` Shahaf Shuler
2018-11-08  9:46     ` ´ð¸´: " Chao Zhu

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='001c01d440cc$a84d20c0$f8e76240$@linux.vnet.ibm.com' \
    --to=chaozhu@linux.vnet.ibm.com \
    --cc=adrien.mazarguil@6wind.com \
    --cc=bluca@debian.org \
    --cc=christian.ehrhardt@canonical.com \
    --cc=dev@dpdk.org \
    --cc=gowrishankar.m@linux.vnet.ibm.com \
    --cc=thomasm@mellanox.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.