DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] [PATCH 0/2] gcc build fix
@ 2020-11-27  8:09 Ruifeng Wang
  2020-11-27  8:09 ` [dpdk-dev] [PATCH 1/2] eal/arm: fix gcc build for optimization level 0 Ruifeng Wang
                   ` (3 more replies)
  0 siblings, 4 replies; 23+ messages in thread
From: Ruifeng Wang @ 2020-11-27  8:09 UTC (permalink / raw)
  Cc: dev, honnappa.nagarahalli, nd, Ruifeng Wang

This series fixed issues found when building project
with Gcc '-O0' option.

Ruifeng Wang (2):
  eal/arm: fix gcc build for optimization level 0
  net/igc: fix gcc build for optimization level 0

 drivers/net/igc/base/meson.build           | 3 ++-
 lib/librte_eal/arm/include/rte_atomic_64.h | 4 ++++
 2 files changed, 6 insertions(+), 1 deletion(-)

-- 
2.20.1


^ permalink raw reply	[flat|nested] 23+ messages in thread

* [dpdk-dev] [PATCH 1/2] eal/arm: fix gcc build for optimization level 0
  2020-11-27  8:09 [dpdk-dev] [PATCH 0/2] gcc build fix Ruifeng Wang
@ 2020-11-27  8:09 ` Ruifeng Wang
  2020-11-27  8:39   ` David Marchand
  2020-11-27  8:09 ` [dpdk-dev] [PATCH 2/2] net/igc: " Ruifeng Wang
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 23+ messages in thread
From: Ruifeng Wang @ 2020-11-27  8:09 UTC (permalink / raw)
  To: Jerin Jacob, Ruifeng Wang, Honnappa Nagarahalli; +Cc: dev, nd, Feifei Wang

Gcc build with '-O0' on platforms with RTE_ARM_FEATURE_ATOMICS set
failed for:
 ../lib/librte_efd/rte_efd.c
 Assembler messages:
3866: Error: selected processor does not support `crc32cb w0,w0,w1'
3890: Error: selected processor does not support `crc32ch w0,w0,w1'
3914: Error: selected processor does not support `crc32cw w0,w0,w1'
3938: Error: selected processor does not support `crc32cx w0,w0,x1'

This was caused by an architecture specifier added for Clang.
Unlike Clang, Gcc considers each inline assembly block to be dependent
and therefor, the architecture specifier impacts assemble of some
blocks require certain extension support.

Removed the architecture for Gcc to fix the issue.

Fixes: 8fce34cd0a6a ("eal/arm: fix clang build of native target")

Reported-by: Feifei Wang <feifei.wang2@arm.com>
Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
---
 lib/librte_eal/arm/include/rte_atomic_64.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lib/librte_eal/arm/include/rte_atomic_64.h b/lib/librte_eal/arm/include/rte_atomic_64.h
index 7fcd17466..467d32a45 100644
--- a/lib/librte_eal/arm/include/rte_atomic_64.h
+++ b/lib/librte_eal/arm/include/rte_atomic_64.h
@@ -46,7 +46,11 @@ rte_atomic_thread_fence(int memorder)
 /*------------------------ 128 bit atomic operations -------------------------*/
 
 #if defined(__ARM_FEATURE_ATOMICS) || defined(RTE_ARM_FEATURE_ATOMICS)
+#if defined(RTE_CC_CLANG)
 #define __LSE_PREAMBLE	".arch armv8-a+lse\n"
+#else
+#define __LSE_PREAMBLE	""
+#endif
 
 #define __ATOMIC128_CAS_OP(cas_op_name, op_string)                          \
 static __rte_noinline rte_int128_t                                          \
-- 
2.20.1


^ permalink raw reply	[flat|nested] 23+ messages in thread

* [dpdk-dev] [PATCH 2/2] net/igc: fix gcc build for optimization level 0
  2020-11-27  8:09 [dpdk-dev] [PATCH 0/2] gcc build fix Ruifeng Wang
  2020-11-27  8:09 ` [dpdk-dev] [PATCH 1/2] eal/arm: fix gcc build for optimization level 0 Ruifeng Wang
@ 2020-11-27  8:09 ` Ruifeng Wang
  2020-11-27  8:53   ` Jerin Jacob
  2020-11-27  9:02   ` David Marchand
  2020-11-27 10:15 ` [dpdk-dev] [PATCH v2 0/2] gcc build fix Ruifeng Wang
  2020-11-27 16:03 ` [dpdk-dev] [PATCH " Thomas Monjalon
  3 siblings, 2 replies; 23+ messages in thread
From: Ruifeng Wang @ 2020-11-27  8:09 UTC (permalink / raw)
  To: Jeff Guo, Haiyue Wang, Alvin Zhang, Ferruh Yigit
  Cc: dev, honnappa.nagarahalli, nd, Ruifeng Wang, Feifei Wang

Gcc build with '-O0' failed for:
 ../drivers/net/igc/base/igc_api.c
 Assembler messages:
29: Error: selected processor does not support `casp x0,x1,x2,x3,[x4]'
82: Error: selected processor does not support `caspa x0,x1,x2,x3,[x4]'
135: Error: selected processor does not support `caspl x0,x1,x2,x3,[x4]'
188: Error: selected processor does not support `caspal x0,x1,x2,x3,[x4]'

This is due to c_args not been passed to meson.

Fixes: 8cb7c57d9b3c ("net/igc: support device initialization")
Cc: alvinx.zhang@intel.com

Reported-by: Feifei Wang <feifei.wang2@arm.com>
Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
---
 drivers/net/igc/base/meson.build | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/igc/base/meson.build b/drivers/net/igc/base/meson.build
index 299985180..690704fe0 100644
--- a/drivers/net/igc/base/meson.build
+++ b/drivers/net/igc/base/meson.build
@@ -13,6 +13,7 @@ sources = [
 ]
 
 base_lib = static_library('igc_base', sources,
-	dependencies: static_rte_eal)
+	dependencies: static_rte_eal,
+	c_args: cflags)
 
 base_objs = base_lib.extract_all_objects()
-- 
2.20.1


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [dpdk-dev] [PATCH 1/2] eal/arm: fix gcc build for optimization level 0
  2020-11-27  8:09 ` [dpdk-dev] [PATCH 1/2] eal/arm: fix gcc build for optimization level 0 Ruifeng Wang
@ 2020-11-27  8:39   ` David Marchand
  2020-11-27  8:51     ` Jerin Jacob
  2020-11-27  9:36     ` Ruifeng Wang
  0 siblings, 2 replies; 23+ messages in thread
From: David Marchand @ 2020-11-27  8:39 UTC (permalink / raw)
  To: Ruifeng Wang, Jerin Jacob; +Cc: Honnappa Nagarahalli, dev, nd, Feifei Wang

On Fri, Nov 27, 2020 at 9:10 AM Ruifeng Wang <ruifeng.wang@arm.com> wrote:
>
> Gcc build with '-O0' on platforms with RTE_ARM_FEATURE_ATOMICS set
> failed for:
>  ../lib/librte_efd/rte_efd.c
>  Assembler messages:
> 3866: Error: selected processor does not support `crc32cb w0,w0,w1'
> 3890: Error: selected processor does not support `crc32ch w0,w0,w1'
> 3914: Error: selected processor does not support `crc32cw w0,w0,w1'
> 3938: Error: selected processor does not support `crc32cx w0,w0,x1'
>
> This was caused by an architecture specifier added for Clang.
> Unlike Clang, Gcc considers each inline assembly block to be dependent
> and therefor, the architecture specifier impacts assemble of some
> blocks require certain extension support.

I reproduced this error with -O0 for config/arm/arm64_octeontx2_linux_gcc.
The patch looks simple enough and it only affects ARM builds.

Jerin,
Are you okay with this change for 20.11?
Or should we wait 21.02?

Ruifeng,
Looking at the kernel, I see no distinction with gcc/clang, so I'd say
the kernel has the same issue, or is there something else that differs
in dpdk?
Besides, the kernel patch previously mentioned had a followup fix.


-- 
David Marchand


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [dpdk-dev] [PATCH 1/2] eal/arm: fix gcc build for optimization level 0
  2020-11-27  8:39   ` David Marchand
@ 2020-11-27  8:51     ` Jerin Jacob
  2020-11-27  9:25       ` David Marchand
  2020-11-27  9:36     ` Ruifeng Wang
  1 sibling, 1 reply; 23+ messages in thread
From: Jerin Jacob @ 2020-11-27  8:51 UTC (permalink / raw)
  To: David Marchand
  Cc: Ruifeng Wang, Jerin Jacob, Honnappa Nagarahalli, dev, nd, Feifei Wang

On Fri, Nov 27, 2020 at 2:09 PM David Marchand
<david.marchand@redhat.com> wrote:
>
> On Fri, Nov 27, 2020 at 9:10 AM Ruifeng Wang <ruifeng.wang@arm.com> wrote:
> >
> > Gcc build with '-O0' on platforms with RTE_ARM_FEATURE_ATOMICS set
> > failed for:
> >  ../lib/librte_efd/rte_efd.c
> >  Assembler messages:
> > 3866: Error: selected processor does not support `crc32cb w0,w0,w1'
> > 3890: Error: selected processor does not support `crc32ch w0,w0,w1'
> > 3914: Error: selected processor does not support `crc32cw w0,w0,w1'
> > 3938: Error: selected processor does not support `crc32cx w0,w0,x1'
> >
> > This was caused by an architecture specifier added for Clang.
> > Unlike Clang, Gcc considers each inline assembly block to be dependent
> > and therefor, the architecture specifier impacts assemble of some
> > blocks require certain extension support.
>
> I reproduced this error with -O0 for config/arm/arm64_octeontx2_linux_gcc.
> The patch looks simple enough and it only affects ARM builds.
>
> Jerin,
> Are you okay with this change for 20.11?
> Or should we wait 21.02?

I could reproduce the issue with meson  build -Dbuildtype=debug
--cross-file config/arm/arm64_octeontx2_linux_gcc

This fix is OK. Request to merge for 20.11

Acked-by: Jerin Jacob <jerinj@marvell.com>


>
> Ruifeng,
> Looking at the kernel, I see no distinction with gcc/clang, so I'd say
> the kernel has the same issue, or is there something else that differs
> in dpdk?
> Besides, the kernel patch previously mentioned had a followup fix.
>
>
> --
> David Marchand
>

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [dpdk-dev] [PATCH 2/2] net/igc: fix gcc build for optimization level 0
  2020-11-27  8:09 ` [dpdk-dev] [PATCH 2/2] net/igc: " Ruifeng Wang
@ 2020-11-27  8:53   ` Jerin Jacob
  2020-11-27  9:02   ` David Marchand
  1 sibling, 0 replies; 23+ messages in thread
From: Jerin Jacob @ 2020-11-27  8:53 UTC (permalink / raw)
  To: Ruifeng Wang
  Cc: Jeff Guo, Haiyue Wang, Alvin Zhang, Ferruh Yigit, dpdk-dev,
	Honnappa Nagarahalli, nd, Feifei Wang

On Fri, Nov 27, 2020 at 1:40 PM Ruifeng Wang <ruifeng.wang@arm.com> wrote:
>
> Gcc build with '-O0' failed for:
>  ../drivers/net/igc/base/igc_api.c
>  Assembler messages:
> 29: Error: selected processor does not support `casp x0,x1,x2,x3,[x4]'
> 82: Error: selected processor does not support `caspa x0,x1,x2,x3,[x4]'
> 135: Error: selected processor does not support `caspl x0,x1,x2,x3,[x4]'
> 188: Error: selected processor does not support `caspal x0,x1,x2,x3,[x4]'
>
> This is due to c_args not been passed to meson.
>
> Fixes: 8cb7c57d9b3c ("net/igc: support device initialization")
> Cc: alvinx.zhang@intel.com
>
> Reported-by: Feifei Wang <feifei.wang2@arm.com>
> Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>


Able to reproduce the issue with meson  build -Dbuildtype=debug
--cross-file config/arm/arm64_octeontx2_linux_gcc and
verified the build issue.

Tested-by: Jerin Jacob <jerinj@marvell.com>


> ---
>  drivers/net/igc/base/meson.build | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/igc/base/meson.build b/drivers/net/igc/base/meson.build
> index 299985180..690704fe0 100644
> --- a/drivers/net/igc/base/meson.build
> +++ b/drivers/net/igc/base/meson.build
> @@ -13,6 +13,7 @@ sources = [
>  ]
>
>  base_lib = static_library('igc_base', sources,
> -       dependencies: static_rte_eal)
> +       dependencies: static_rte_eal,
> +       c_args: cflags)
>
>  base_objs = base_lib.extract_all_objects()
> --
> 2.20.1
>

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [dpdk-dev] [PATCH 2/2] net/igc: fix gcc build for optimization level 0
  2020-11-27  8:09 ` [dpdk-dev] [PATCH 2/2] net/igc: " Ruifeng Wang
  2020-11-27  8:53   ` Jerin Jacob
@ 2020-11-27  9:02   ` David Marchand
  2020-11-27 12:13     ` David Marchand
  1 sibling, 1 reply; 23+ messages in thread
From: David Marchand @ 2020-11-27  9:02 UTC (permalink / raw)
  To: Bruce Richardson, Yigit, Ferruh
  Cc: Jeff Guo, Haiyue Wang, Alvin Zhang, dev, Honnappa Nagarahalli,
	nd, Ruifeng Wang, Feifei Wang

On Fri, Nov 27, 2020 at 9:10 AM Ruifeng Wang <ruifeng.wang@arm.com> wrote:
>
> Gcc build with '-O0' failed for:
>  ../drivers/net/igc/base/igc_api.c
>  Assembler messages:
> 29: Error: selected processor does not support `casp x0,x1,x2,x3,[x4]'
> 82: Error: selected processor does not support `caspa x0,x1,x2,x3,[x4]'
> 135: Error: selected processor does not support `caspl x0,x1,x2,x3,[x4]'
> 188: Error: selected processor does not support `caspal x0,x1,x2,x3,[x4]'
>
> This is due to c_args not been passed to meson.
>
> Fixes: 8cb7c57d9b3c ("net/igc: support device initialization")
> Cc: alvinx.zhang@intel.com
>
> Reported-by: Feifei Wang <feifei.wang2@arm.com>
> Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>

I did not get to reproduce it yet (get an error on first patch...).

The patch looks fine but I fear some compilation problems since a lot
of base drivers filter cflags.
Still waiting for CI results...

Bruce,Ferruh,
Wdyt?


-- 
David Marchand


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [dpdk-dev] [PATCH 1/2] eal/arm: fix gcc build for optimization level 0
  2020-11-27  8:51     ` Jerin Jacob
@ 2020-11-27  9:25       ` David Marchand
  2020-11-27  9:33         ` Jerin Jacob
  2020-11-27  9:39         ` Andrew Rybchenko
  0 siblings, 2 replies; 23+ messages in thread
From: David Marchand @ 2020-11-27  9:25 UTC (permalink / raw)
  To: Ruifeng Wang, Andrew Rybchenko
  Cc: Jerin Jacob, Honnappa Nagarahalli, dev, nd, Feifei Wang, Jerin Jacob

On Fri, Nov 27, 2020 at 9:51 AM Jerin Jacob <jerinjacobk@gmail.com> wrote:
>
> On Fri, Nov 27, 2020 at 2:09 PM David Marchand
> <david.marchand@redhat.com> wrote:
> >
> > On Fri, Nov 27, 2020 at 9:10 AM Ruifeng Wang <ruifeng.wang@arm.com> wrote:
> > >
> > > Gcc build with '-O0' on platforms with RTE_ARM_FEATURE_ATOMICS set
> > > failed for:
> > >  ../lib/librte_efd/rte_efd.c
> > >  Assembler messages:
> > > 3866: Error: selected processor does not support `crc32cb w0,w0,w1'
> > > 3890: Error: selected processor does not support `crc32ch w0,w0,w1'
> > > 3914: Error: selected processor does not support `crc32cw w0,w0,w1'
> > > 3938: Error: selected processor does not support `crc32cx w0,w0,x1'
> > >
> > > This was caused by an architecture specifier added for Clang.
> > > Unlike Clang, Gcc considers each inline assembly block to be dependent
> > > and therefor, the architecture specifier impacts assemble of some
> > > blocks require certain extension support.
> >
> > I reproduced this error with -O0 for config/arm/arm64_octeontx2_linux_gcc.
> > The patch looks simple enough and it only affects ARM builds.
> >
> > Jerin,
> > Are you okay with this change for 20.11?
> > Or should we wait 21.02?
>
> I could reproduce the issue with meson  build -Dbuildtype=debug
> --cross-file config/arm/arm64_octeontx2_linux_gcc
>
> This fix is OK. Request to merge for 20.11
>
> Acked-by: Jerin Jacob <jerinj@marvell.com>

Ruifeng, Andrew,

I get a compilation error with this patch on sfc using gcc and
config/arm/arm64_octeontx2_linux_gcc config + --buildtype=debug and/or
-Dc_args=-O0 .

aarch64-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture
8.2-2019.01 (arm-rel-8.28)) 8.2.1 20180802

FAILED: drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_crc32.c.o
aarch64-linux-gnu-gcc
-Idrivers/common/sfc_efx/base/932d09a@@sfc_base@sta
-Idrivers/common/sfc_efx/base -I../../dpdk/drivers/common/sfc_efx/base
-Idrivers/common/sfc_efx -I../../dpdk/drivers/common/sfc_efx -I.
-I../../dpdk/ -Iconfig -I../../dpdk/config -Ilib/librte_eal/include
-I../../dpdk/lib/librte_eal/include -Ilib/librte_eal/linux/include
-I../../dpdk/lib/librte_eal/linux/include -Ilib/librte_eal/arm/include
-I../../dpdk/lib/librte_eal/arm/include -Ilib/librte_eal/common
-I../../dpdk/lib/librte_eal/common -Ilib/librte_eal
-I../../dpdk/lib/librte_eal -Ilib/librte_kvargs
-I../../dpdk/lib/librte_kvargs
-Ilib/librte_telemetry/../librte_metrics
-I../../dpdk/lib/librte_telemetry/../librte_metrics
-Ilib/librte_telemetry -I../../dpdk/lib/librte_telemetry
-fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall
-Winvalid-pch -Werror -g -include rte_config.h -Wextra -Wcast-qual
-Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security
-Wmissing-declarations -Wmissing-prototypes -Wnested-externs
-Wold-style-definition -Wpointer-arith -Wsign-compare
-Wstrict-prototypes -Wundef -Wwrite-strings -Wno-packed-not-aligned
-Wno-missing-field-initializers -D_GNU_SOURCE -fPIC
-march=armv8.2-a+crc+crypto+lse -DALLOW_EXPERIMENTAL_API
-DALLOW_INTERNAL_API -Wno-format-truncation -Wdisabled-optimization
-Waggregate-return -Wbad-function-cast -Wno-sign-compare
-Wno-unused-parameter -Wno-unused-variable -Wno-empty-body
-Wno-unused-but-set-variable -MD -MQ
'drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_crc32.c.o' -MF
'drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_crc32.c.o.d' -o
'drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_crc32.c.o' -c
../../dpdk/drivers/common/sfc_efx/base/efx_crc32.c
In file included from ../../dpdk/lib/librte_eal/arm/include/rte_atomic.h:9,
                 from ../../dpdk/lib/librte_eal/include/generic/rte_pause.h:19,
                 from ../../dpdk/lib/librte_eal/arm/include/rte_pause_64.h:19,
                 from ../../dpdk/lib/librte_eal/arm/include/rte_pause.h:13,
                 from
../../dpdk/lib/librte_eal/include/generic/rte_spinlock.h:25,
                 from ../../dpdk/lib/librte_eal/arm/include/rte_spinlock.h:17,
                 from ../../dpdk/drivers/common/sfc_efx/efsys.h:15,
                 from ../../dpdk/drivers/common/sfc_efx/base/efx.h:11,
                 from ../../dpdk/drivers/common/sfc_efx/base/efx_crc32.c:7:
../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h: In function
‘__cas_128_relaxed’:
../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:81:20: error:
function returns an aggregate [-Werror=aggregate-return]
 __ATOMIC128_CAS_OP(__cas_128_relaxed, "casp")
                    ^~~~~~~~~~~~~~~~~
../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:57:1: note: in
definition of macro ‘__ATOMIC128_CAS_OP’
 cas_op_name(rte_int128_t *dst, rte_int128_t old, rte_int128_t updated)      \
 ^~~~~~~~~~~
../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h: In function
‘__cas_128_acquire’:
../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:82:20: error:
function returns an aggregate [-Werror=aggregate-return]
 __ATOMIC128_CAS_OP(__cas_128_acquire, "caspa")
                    ^~~~~~~~~~~~~~~~~
../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:57:1: note: in
definition of macro ‘__ATOMIC128_CAS_OP’
 cas_op_name(rte_int128_t *dst, rte_int128_t old, rte_int128_t updated)      \
 ^~~~~~~~~~~
../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h: In function
‘__cas_128_release’:
../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:83:20: error:
function returns an aggregate [-Werror=aggregate-return]
 __ATOMIC128_CAS_OP(__cas_128_release, "caspl")
                    ^~~~~~~~~~~~~~~~~
../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:57:1: note: in
definition of macro ‘__ATOMIC128_CAS_OP’
 cas_op_name(rte_int128_t *dst, rte_int128_t old, rte_int128_t updated)      \
 ^~~~~~~~~~~
../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h: In function
‘__cas_128_acq_rel’:
../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:84:20: error:
function returns an aggregate [-Werror=aggregate-return]
 __ATOMIC128_CAS_OP(__cas_128_acq_rel, "caspal")
                    ^~~~~~~~~~~~~~~~~
../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:57:1: note: in
definition of macro ‘__ATOMIC128_CAS_OP’
 cas_op_name(rte_int128_t *dst, rte_int128_t old, rte_int128_t updated)      \
 ^~~~~~~~~~~
cc1: all warnings being treated as errors


If I waive those warnings:
- next to fail is net/igc (fixed by next patch so ok)
- and then next to fail is net/sfc.


-- 
David Marchand


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [dpdk-dev] [PATCH 1/2] eal/arm: fix gcc build for optimization level 0
  2020-11-27  9:25       ` David Marchand
@ 2020-11-27  9:33         ` Jerin Jacob
  2020-11-27  9:45           ` David Marchand
  2020-11-27  9:39         ` Andrew Rybchenko
  1 sibling, 1 reply; 23+ messages in thread
From: Jerin Jacob @ 2020-11-27  9:33 UTC (permalink / raw)
  To: David Marchand
  Cc: Ruifeng Wang, Andrew Rybchenko, Jerin Jacob,
	Honnappa Nagarahalli, dev, nd, Feifei Wang

On Fri, Nov 27, 2020 at 2:56 PM David Marchand
<david.marchand@redhat.com> wrote:
>
> On Fri, Nov 27, 2020 at 9:51 AM Jerin Jacob <jerinjacobk@gmail.com> wrote:
> >
> > On Fri, Nov 27, 2020 at 2:09 PM David Marchand
> > <david.marchand@redhat.com> wrote:
> > >
> > > On Fri, Nov 27, 2020 at 9:10 AM Ruifeng Wang <ruifeng.wang@arm.com> wrote:
> > > >
> > > > Gcc build with '-O0' on platforms with RTE_ARM_FEATURE_ATOMICS set
> > > > failed for:
> > > >  ../lib/librte_efd/rte_efd.c
> > > >  Assembler messages:
> > > > 3866: Error: selected processor does not support `crc32cb w0,w0,w1'
> > > > 3890: Error: selected processor does not support `crc32ch w0,w0,w1'
> > > > 3914: Error: selected processor does not support `crc32cw w0,w0,w1'
> > > > 3938: Error: selected processor does not support `crc32cx w0,w0,x1'
> > > >
> > > > This was caused by an architecture specifier added for Clang.
> > > > Unlike Clang, Gcc considers each inline assembly block to be dependent
> > > > and therefor, the architecture specifier impacts assemble of some
> > > > blocks require certain extension support.
> > >
> > > I reproduced this error with -O0 for config/arm/arm64_octeontx2_linux_gcc.
> > > The patch looks simple enough and it only affects ARM builds.
> > >
> > > Jerin,
> > > Are you okay with this change for 20.11?
> > > Or should we wait 21.02?
> >
> > I could reproduce the issue with meson  build -Dbuildtype=debug
> > --cross-file config/arm/arm64_octeontx2_linux_gcc
> >
> > This fix is OK. Request to merge for 20.11
> >
> > Acked-by: Jerin Jacob <jerinj@marvell.com>
>
> Ruifeng, Andrew,
>
> I get a compilation error with this patch on sfc using gcc and
> config/arm/arm64_octeontx2_linux_gcc config + --buildtype=debug and/or
> -Dc_args=-O0 .
>
> aarch64-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture
> 8.2-2019.01 (arm-rel-8.28)) 8.2.1 20180802
>
> FAILED: drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_crc32.c.o
> aarch64-linux-gnu-gcc
> -Idrivers/common/sfc_efx/base/932d09a@@sfc_base@sta
> -Idrivers/common/sfc_efx/base -I../../dpdk/drivers/common/sfc_efx/base
> -Idrivers/common/sfc_efx -I../../dpdk/drivers/common/sfc_efx -I.
> -I../../dpdk/ -Iconfig -I../../dpdk/config -Ilib/librte_eal/include
> -I../../dpdk/lib/librte_eal/include -Ilib/librte_eal/linux/include
> -I../../dpdk/lib/librte_eal/linux/include -Ilib/librte_eal/arm/include
> -I../../dpdk/lib/librte_eal/arm/include -Ilib/librte_eal/common
> -I../../dpdk/lib/librte_eal/common -Ilib/librte_eal
> -I../../dpdk/lib/librte_eal -Ilib/librte_kvargs
> -I../../dpdk/lib/librte_kvargs
> -Ilib/librte_telemetry/../librte_metrics
> -I../../dpdk/lib/librte_telemetry/../librte_metrics
> -Ilib/librte_telemetry -I../../dpdk/lib/librte_telemetry
> -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall
> -Winvalid-pch -Werror -g -include rte_config.h -Wextra -Wcast-qual
> -Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security
> -Wmissing-declarations -Wmissing-prototypes -Wnested-externs
> -Wold-style-definition -Wpointer-arith -Wsign-compare
> -Wstrict-prototypes -Wundef -Wwrite-strings -Wno-packed-not-aligned
> -Wno-missing-field-initializers -D_GNU_SOURCE -fPIC
> -march=armv8.2-a+crc+crypto+lse -DALLOW_EXPERIMENTAL_API
> -DALLOW_INTERNAL_API -Wno-format-truncation -Wdisabled-optimization
> -Waggregate-return -Wbad-function-cast -Wno-sign-compare
> -Wno-unused-parameter -Wno-unused-variable -Wno-empty-body
> -Wno-unused-but-set-variable -MD -MQ
> 'drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_crc32.c.o' -MF
> 'drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_crc32.c.o.d' -o
> 'drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_crc32.c.o' -c
> ../../dpdk/drivers/common/sfc_efx/base/efx_crc32.c
> In file included from ../../dpdk/lib/librte_eal/arm/include/rte_atomic.h:9,
>                  from ../../dpdk/lib/librte_eal/include/generic/rte_pause.h:19,
>                  from ../../dpdk/lib/librte_eal/arm/include/rte_pause_64.h:19,
>                  from ../../dpdk/lib/librte_eal/arm/include/rte_pause.h:13,
>                  from
> ../../dpdk/lib/librte_eal/include/generic/rte_spinlock.h:25,
>                  from ../../dpdk/lib/librte_eal/arm/include/rte_spinlock.h:17,
>                  from ../../dpdk/drivers/common/sfc_efx/efsys.h:15,
>                  from ../../dpdk/drivers/common/sfc_efx/base/efx.h:11,
>                  from ../../dpdk/drivers/common/sfc_efx/base/efx_crc32.c:7:
> ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h: In function
> ‘__cas_128_relaxed’:
> ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:81:20: error:
> function returns an aggregate [-Werror=aggregate-return]
>  __ATOMIC128_CAS_OP(__cas_128_relaxed, "casp")
>                     ^~~~~~~~~~~~~~~~~
> ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:57:1: note: in
> definition of macro ‘__ATOMIC128_CAS_OP’
>  cas_op_name(rte_int128_t *dst, rte_int128_t old, rte_int128_t updated)      \
>  ^~~~~~~~~~~
> ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h: In function
> ‘__cas_128_acquire’:
> ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:82:20: error:
> function returns an aggregate [-Werror=aggregate-return]
>  __ATOMIC128_CAS_OP(__cas_128_acquire, "caspa")
>                     ^~~~~~~~~~~~~~~~~
> ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:57:1: note: in
> definition of macro ‘__ATOMIC128_CAS_OP’
>  cas_op_name(rte_int128_t *dst, rte_int128_t old, rte_int128_t updated)      \
>  ^~~~~~~~~~~
> ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h: In function
> ‘__cas_128_release’:
> ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:83:20: error:
> function returns an aggregate [-Werror=aggregate-return]
>  __ATOMIC128_CAS_OP(__cas_128_release, "caspl")
>                     ^~~~~~~~~~~~~~~~~
> ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:57:1: note: in
> definition of macro ‘__ATOMIC128_CAS_OP’
>  cas_op_name(rte_int128_t *dst, rte_int128_t old, rte_int128_t updated)      \
>  ^~~~~~~~~~~
> ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h: In function
> ‘__cas_128_acq_rel’:
> ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:84:20: error:
> function returns an aggregate [-Werror=aggregate-return]
>  __ATOMIC128_CAS_OP(__cas_128_acq_rel, "caspal")
>                     ^~~~~~~~~~~~~~~~~
> ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:57:1: note: in
> definition of macro ‘__ATOMIC128_CAS_OP’
>  cas_op_name(rte_int128_t *dst, rte_int128_t old, rte_int128_t updated)      \
>  ^~~~~~~~~~~
> cc1: all warnings being treated as errors
>
>
> If I waive those warnings:
> - next to fail is net/igc (fixed by next patch so ok)
> - and then next to fail is net/sfc.

Regarding the net/sfc build, Could try clean build.(I got the warning first,
after the clean build, it is OK)



>
>
> --
> David Marchand
>

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [dpdk-dev] [PATCH 1/2] eal/arm: fix gcc build for optimization level 0
  2020-11-27  8:39   ` David Marchand
  2020-11-27  8:51     ` Jerin Jacob
@ 2020-11-27  9:36     ` Ruifeng Wang
  1 sibling, 0 replies; 23+ messages in thread
From: Ruifeng Wang @ 2020-11-27  9:36 UTC (permalink / raw)
  To: David Marchand, jerinj; +Cc: Honnappa Nagarahalli, dev, nd, Feifei Wang, nd

> -----Original Message-----
> From: David Marchand <david.marchand@redhat.com>
> Sent: Friday, November 27, 2020 4:39 PM
> To: Ruifeng Wang <Ruifeng.Wang@arm.com>; jerinj@marvell.com
> Cc: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>; dev
> <dev@dpdk.org>; nd <nd@arm.com>; Feifei Wang <Feifei.Wang2@arm.com>
> Subject: Re: [dpdk-dev] [PATCH 1/2] eal/arm: fix gcc build for optimization
> level 0
> 
> On Fri, Nov 27, 2020 at 9:10 AM Ruifeng Wang <ruifeng.wang@arm.com>
> wrote:
> >
> > Gcc build with '-O0' on platforms with RTE_ARM_FEATURE_ATOMICS set
> > failed for:
> >  ../lib/librte_efd/rte_efd.c
> >  Assembler messages:
> > 3866: Error: selected processor does not support `crc32cb w0,w0,w1'
> > 3890: Error: selected processor does not support `crc32ch w0,w0,w1'
> > 3914: Error: selected processor does not support `crc32cw w0,w0,w1'
> > 3938: Error: selected processor does not support `crc32cx w0,w0,x1'
> >
> > This was caused by an architecture specifier added for Clang.
> > Unlike Clang, Gcc considers each inline assembly block to be dependent
> > and therefor, the architecture specifier impacts assemble of some
> > blocks require certain extension support.
> 
> I reproduced this error with -O0 for config/arm/arm64_octeontx2_linux_gcc.
> The patch looks simple enough and it only affects ARM builds.
> 
> Jerin,
> Are you okay with this change for 20.11?
> Or should we wait 21.02?
> 
> Ruifeng,
> Looking at the kernel, I see no distinction with gcc/clang, so I'd say the kernel
> has the same issue, or is there something else that differs in dpdk?
> Besides, the kernel patch previously mentioned had a followup fix.

The kernel follow up fix looks like a better way to reconcile Gcc and Clang.
I'll reroll with the same approach.
> 
> 
> --
> David Marchand


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [dpdk-dev] [PATCH 1/2] eal/arm: fix gcc build for optimization level 0
  2020-11-27  9:25       ` David Marchand
  2020-11-27  9:33         ` Jerin Jacob
@ 2020-11-27  9:39         ` Andrew Rybchenko
  1 sibling, 0 replies; 23+ messages in thread
From: Andrew Rybchenko @ 2020-11-27  9:39 UTC (permalink / raw)
  To: David Marchand, Ruifeng Wang
  Cc: Jerin Jacob, Honnappa Nagarahalli, dev, nd, Feifei Wang, Jerin Jacob

On 11/27/20 12:25 PM, David Marchand wrote:
> On Fri, Nov 27, 2020 at 9:51 AM Jerin Jacob <jerinjacobk@gmail.com> wrote:
>>
>> On Fri, Nov 27, 2020 at 2:09 PM David Marchand
>> <david.marchand@redhat.com> wrote:
>>>
>>> On Fri, Nov 27, 2020 at 9:10 AM Ruifeng Wang <ruifeng.wang@arm.com> wrote:
>>>>
>>>> Gcc build with '-O0' on platforms with RTE_ARM_FEATURE_ATOMICS set
>>>> failed for:
>>>>  ../lib/librte_efd/rte_efd.c
>>>>  Assembler messages:
>>>> 3866: Error: selected processor does not support `crc32cb w0,w0,w1'
>>>> 3890: Error: selected processor does not support `crc32ch w0,w0,w1'
>>>> 3914: Error: selected processor does not support `crc32cw w0,w0,w1'
>>>> 3938: Error: selected processor does not support `crc32cx w0,w0,x1'
>>>>
>>>> This was caused by an architecture specifier added for Clang.
>>>> Unlike Clang, Gcc considers each inline assembly block to be dependent
>>>> and therefor, the architecture specifier impacts assemble of some
>>>> blocks require certain extension support.
>>>
>>> I reproduced this error with -O0 for config/arm/arm64_octeontx2_linux_gcc.
>>> The patch looks simple enough and it only affects ARM builds.
>>>
>>> Jerin,
>>> Are you okay with this change for 20.11?
>>> Or should we wait 21.02?
>>
>> I could reproduce the issue with meson  build -Dbuildtype=debug
>> --cross-file config/arm/arm64_octeontx2_linux_gcc
>>
>> This fix is OK. Request to merge for 20.11
>>
>> Acked-by: Jerin Jacob <jerinj@marvell.com>
> 
> Ruifeng, Andrew,
> 
> I get a compilation error with this patch on sfc using gcc and
> config/arm/arm64_octeontx2_linux_gcc config + --buildtype=debug and/or
> -Dc_args=-O0 .
> 
> aarch64-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture
> 8.2-2019.01 (arm-rel-8.28)) 8.2.1 20180802
> 
> FAILED: drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_crc32.c.o
> aarch64-linux-gnu-gcc
> -Idrivers/common/sfc_efx/base/932d09a@@sfc_base@sta
> -Idrivers/common/sfc_efx/base -I../../dpdk/drivers/common/sfc_efx/base
> -Idrivers/common/sfc_efx -I../../dpdk/drivers/common/sfc_efx -I.
> -I../../dpdk/ -Iconfig -I../../dpdk/config -Ilib/librte_eal/include
> -I../../dpdk/lib/librte_eal/include -Ilib/librte_eal/linux/include
> -I../../dpdk/lib/librte_eal/linux/include -Ilib/librte_eal/arm/include
> -I../../dpdk/lib/librte_eal/arm/include -Ilib/librte_eal/common
> -I../../dpdk/lib/librte_eal/common -Ilib/librte_eal
> -I../../dpdk/lib/librte_eal -Ilib/librte_kvargs
> -I../../dpdk/lib/librte_kvargs
> -Ilib/librte_telemetry/../librte_metrics
> -I../../dpdk/lib/librte_telemetry/../librte_metrics
> -Ilib/librte_telemetry -I../../dpdk/lib/librte_telemetry
> -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall
> -Winvalid-pch -Werror -g -include rte_config.h -Wextra -Wcast-qual
> -Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security
> -Wmissing-declarations -Wmissing-prototypes -Wnested-externs
> -Wold-style-definition -Wpointer-arith -Wsign-compare
> -Wstrict-prototypes -Wundef -Wwrite-strings -Wno-packed-not-aligned
> -Wno-missing-field-initializers -D_GNU_SOURCE -fPIC
> -march=armv8.2-a+crc+crypto+lse -DALLOW_EXPERIMENTAL_API
> -DALLOW_INTERNAL_API -Wno-format-truncation -Wdisabled-optimization
> -Waggregate-return -Wbad-function-cast -Wno-sign-compare
> -Wno-unused-parameter -Wno-unused-variable -Wno-empty-body
> -Wno-unused-but-set-variable -MD -MQ
> 'drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_crc32.c.o' -MF
> 'drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_crc32.c.o.d' -o
> 'drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_crc32.c.o' -c
> ../../dpdk/drivers/common/sfc_efx/base/efx_crc32.c
> In file included from ../../dpdk/lib/librte_eal/arm/include/rte_atomic.h:9,
>                  from ../../dpdk/lib/librte_eal/include/generic/rte_pause.h:19,
>                  from ../../dpdk/lib/librte_eal/arm/include/rte_pause_64.h:19,
>                  from ../../dpdk/lib/librte_eal/arm/include/rte_pause.h:13,
>                  from
> ../../dpdk/lib/librte_eal/include/generic/rte_spinlock.h:25,
>                  from ../../dpdk/lib/librte_eal/arm/include/rte_spinlock.h:17,
>                  from ../../dpdk/drivers/common/sfc_efx/efsys.h:15,
>                  from ../../dpdk/drivers/common/sfc_efx/base/efx.h:11,
>                  from ../../dpdk/drivers/common/sfc_efx/base/efx_crc32.c:7:

...

> If I waive those warnings:
> - next to fail is net/igc (fixed by next patch so ok)
> - and then next to fail is net/sfc.

As I understand it is not common/sfc_efx specific issue since it is
simply header inclusion. I guess it is the just first
one to build. I have no good ideas what to do with it.
So, help from ARM experts would be appreciated.

Andrew.


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [dpdk-dev] [PATCH 1/2] eal/arm: fix gcc build for optimization level 0
  2020-11-27  9:33         ` Jerin Jacob
@ 2020-11-27  9:45           ` David Marchand
  2020-11-27 10:05             ` Ruifeng Wang
  0 siblings, 1 reply; 23+ messages in thread
From: David Marchand @ 2020-11-27  9:45 UTC (permalink / raw)
  To: Jerin Jacob
  Cc: Ruifeng Wang, Andrew Rybchenko, Jerin Jacob,
	Honnappa Nagarahalli, dev, nd, Feifei Wang

On Fri, Nov 27, 2020 at 10:34 AM Jerin Jacob <jerinjacobk@gmail.com> wrote:
>
> On Fri, Nov 27, 2020 at 2:56 PM David Marchand
> <david.marchand@redhat.com> wrote:
> >
> > On Fri, Nov 27, 2020 at 9:51 AM Jerin Jacob <jerinjacobk@gmail.com> wrote:
> > >
> > > On Fri, Nov 27, 2020 at 2:09 PM David Marchand
> > > <david.marchand@redhat.com> wrote:
> > > >
> > > > On Fri, Nov 27, 2020 at 9:10 AM Ruifeng Wang <ruifeng.wang@arm.com> wrote:
> > > > >
> > > > > Gcc build with '-O0' on platforms with RTE_ARM_FEATURE_ATOMICS set
> > > > > failed for:
> > > > >  ../lib/librte_efd/rte_efd.c
> > > > >  Assembler messages:
> > > > > 3866: Error: selected processor does not support `crc32cb w0,w0,w1'
> > > > > 3890: Error: selected processor does not support `crc32ch w0,w0,w1'
> > > > > 3914: Error: selected processor does not support `crc32cw w0,w0,w1'
> > > > > 3938: Error: selected processor does not support `crc32cx w0,w0,x1'
> > > > >
> > > > > This was caused by an architecture specifier added for Clang.
> > > > > Unlike Clang, Gcc considers each inline assembly block to be dependent
> > > > > and therefor, the architecture specifier impacts assemble of some
> > > > > blocks require certain extension support.
> > > >
> > > > I reproduced this error with -O0 for config/arm/arm64_octeontx2_linux_gcc.
> > > > The patch looks simple enough and it only affects ARM builds.
> > > >
> > > > Jerin,
> > > > Are you okay with this change for 20.11?
> > > > Or should we wait 21.02?
> > >
> > > I could reproduce the issue with meson  build -Dbuildtype=debug
> > > --cross-file config/arm/arm64_octeontx2_linux_gcc
> > >
> > > This fix is OK. Request to merge for 20.11
> > >
> > > Acked-by: Jerin Jacob <jerinj@marvell.com>
> >
> > Ruifeng, Andrew,
> >
> > I get a compilation error with this patch on sfc using gcc and
> > config/arm/arm64_octeontx2_linux_gcc config + --buildtype=debug and/or
> > -Dc_args=-O0 .
> >
> > aarch64-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture
> > 8.2-2019.01 (arm-rel-8.28)) 8.2.1 20180802
> >
> > FAILED: drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_crc32.c.o
> > aarch64-linux-gnu-gcc
> > -Idrivers/common/sfc_efx/base/932d09a@@sfc_base@sta
> > -Idrivers/common/sfc_efx/base -I../../dpdk/drivers/common/sfc_efx/base
> > -Idrivers/common/sfc_efx -I../../dpdk/drivers/common/sfc_efx -I.
> > -I../../dpdk/ -Iconfig -I../../dpdk/config -Ilib/librte_eal/include
> > -I../../dpdk/lib/librte_eal/include -Ilib/librte_eal/linux/include
> > -I../../dpdk/lib/librte_eal/linux/include -Ilib/librte_eal/arm/include
> > -I../../dpdk/lib/librte_eal/arm/include -Ilib/librte_eal/common
> > -I../../dpdk/lib/librte_eal/common -Ilib/librte_eal
> > -I../../dpdk/lib/librte_eal -Ilib/librte_kvargs
> > -I../../dpdk/lib/librte_kvargs
> > -Ilib/librte_telemetry/../librte_metrics
> > -I../../dpdk/lib/librte_telemetry/../librte_metrics
> > -Ilib/librte_telemetry -I../../dpdk/lib/librte_telemetry
> > -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall
> > -Winvalid-pch -Werror -g -include rte_config.h -Wextra -Wcast-qual
> > -Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security
> > -Wmissing-declarations -Wmissing-prototypes -Wnested-externs
> > -Wold-style-definition -Wpointer-arith -Wsign-compare
> > -Wstrict-prototypes -Wundef -Wwrite-strings -Wno-packed-not-aligned
> > -Wno-missing-field-initializers -D_GNU_SOURCE -fPIC
> > -march=armv8.2-a+crc+crypto+lse -DALLOW_EXPERIMENTAL_API
> > -DALLOW_INTERNAL_API -Wno-format-truncation -Wdisabled-optimization
> > -Waggregate-return -Wbad-function-cast -Wno-sign-compare
> > -Wno-unused-parameter -Wno-unused-variable -Wno-empty-body
> > -Wno-unused-but-set-variable -MD -MQ
> > 'drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_crc32.c.o' -MF
> > 'drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_crc32.c.o.d' -o
> > 'drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_crc32.c.o' -c
> > ../../dpdk/drivers/common/sfc_efx/base/efx_crc32.c
> > In file included from ../../dpdk/lib/librte_eal/arm/include/rte_atomic.h:9,
> >                  from ../../dpdk/lib/librte_eal/include/generic/rte_pause.h:19,
> >                  from ../../dpdk/lib/librte_eal/arm/include/rte_pause_64.h:19,
> >                  from ../../dpdk/lib/librte_eal/arm/include/rte_pause.h:13,
> >                  from
> > ../../dpdk/lib/librte_eal/include/generic/rte_spinlock.h:25,
> >                  from ../../dpdk/lib/librte_eal/arm/include/rte_spinlock.h:17,
> >                  from ../../dpdk/drivers/common/sfc_efx/efsys.h:15,
> >                  from ../../dpdk/drivers/common/sfc_efx/base/efx.h:11,
> >                  from ../../dpdk/drivers/common/sfc_efx/base/efx_crc32.c:7:
> > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h: In function
> > ‘__cas_128_relaxed’:
> > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:81:20: error:
> > function returns an aggregate [-Werror=aggregate-return]
> >  __ATOMIC128_CAS_OP(__cas_128_relaxed, "casp")
> >                     ^~~~~~~~~~~~~~~~~
> > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:57:1: note: in
> > definition of macro ‘__ATOMIC128_CAS_OP’
> >  cas_op_name(rte_int128_t *dst, rte_int128_t old, rte_int128_t updated)      \
> >  ^~~~~~~~~~~
> > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h: In function
> > ‘__cas_128_acquire’:
> > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:82:20: error:
> > function returns an aggregate [-Werror=aggregate-return]
> >  __ATOMIC128_CAS_OP(__cas_128_acquire, "caspa")
> >                     ^~~~~~~~~~~~~~~~~
> > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:57:1: note: in
> > definition of macro ‘__ATOMIC128_CAS_OP’
> >  cas_op_name(rte_int128_t *dst, rte_int128_t old, rte_int128_t updated)      \
> >  ^~~~~~~~~~~
> > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h: In function
> > ‘__cas_128_release’:
> > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:83:20: error:
> > function returns an aggregate [-Werror=aggregate-return]
> >  __ATOMIC128_CAS_OP(__cas_128_release, "caspl")
> >                     ^~~~~~~~~~~~~~~~~
> > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:57:1: note: in
> > definition of macro ‘__ATOMIC128_CAS_OP’
> >  cas_op_name(rte_int128_t *dst, rte_int128_t old, rte_int128_t updated)      \
> >  ^~~~~~~~~~~
> > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h: In function
> > ‘__cas_128_acq_rel’:
> > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:84:20: error:
> > function returns an aggregate [-Werror=aggregate-return]
> >  __ATOMIC128_CAS_OP(__cas_128_acq_rel, "caspal")
> >                     ^~~~~~~~~~~~~~~~~
> > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:57:1: note: in
> > definition of macro ‘__ATOMIC128_CAS_OP’
> >  cas_op_name(rte_int128_t *dst, rte_int128_t old, rte_int128_t updated)      \
> >  ^~~~~~~~~~~
> > cc1: all warnings being treated as errors
> >
> >
> > If I waive those warnings:
> > - next to fail is net/igc (fixed by next patch so ok)
> > - and then next to fail is net/sfc.
>
> Regarding the net/sfc build, Could try clean build.(I got the warning first,
> after the clean build, it is OK)

That's what I first thought too, then I noticed that
test-meson-builds.sh had switched back my build dir to debugoptimized.


From scratch:

The Meson build system
Version: 0.52.0
Source dir: /home/dmarchan/dpdk
Build dir: /home/dmarchan/builds/build-arm64-octeontx2
Build type: cross build
Program cat found: YES (/usr/bin/cat)
Project name: DPDK
Project version: 20.11.0-rc5
Appending CFLAGS from environment: '-Werror'
C compiler for the build machine: ccache gcc (gcc 9.3.1 "gcc (GCC)
9.3.1 20200408 (Red Hat 9.3.1-2)")
C linker for the build machine: GNU ld.bfd 2.32-33
C compiler for the host machine: aarch64-linux-gnu-gcc (gcc 8.2.1
"aarch64-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture
8.2-2019.01 (arm-rel-8.28)) 8.2.1 20180802")
C linker for the host machine: GNU ld.bfd 8.2-2019
Build machine cpu family: x86_64
Build machine cpu: x86_64
Host machine cpu family: aarch64
Host machine cpu: armv8-a
Target machine cpu family: aarch64
Target machine cpu: armv8-a
...
Option buildtype is: debug [default: release]
Option default_library is: shared [default: static]
Found ninja-1.9.0 at /usr/bin/ninja
ninja: Entering directory `/home/dmarchan/builds/build-arm64-octeontx2'
[479/2558] Compiling C object
'drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_bootcfg.c.o'.
FAILED: drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_bootcfg.c.o
aarch64-linux-gnu-gcc
-Idrivers/common/sfc_efx/base/932d09a@@sfc_base@sta
-Idrivers/common/sfc_efx/base -I../../dpdk/drivers/common/sfc_efx/base
-Idrivers/common/sfc_efx -I../../dpdk/drivers/common/sfc_efx -I.
-I../../dpdk/ -Iconfig -I../../dpdk/config -Ilib/librte_eal/include
-I../../dpdk/lib/librte_eal/include -Ilib/librte_eal/linux/include
-I../../dpdk/lib/librte_eal/linux/include -Ilib/librte_eal/arm/include
-I../../dpdk/lib/librte_eal/arm/include -Ilib/librte_eal/common
-I../../dpdk/lib/librte_eal/common -Ilib/librte_eal
-I../../dpdk/lib/librte_eal -Ilib/librte_kvargs
-I../../dpdk/lib/librte_kvargs
-Ilib/librte_telemetry/../librte_metrics
-I../../dpdk/lib/librte_telemetry/../librte_metrics
-Ilib/librte_telemetry -I../../dpdk/lib/librte_telemetry
-fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall
-Winvalid-pch -Werror -g -include rte_config.h -Wextra -Wcast-qual
-Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security
-Wmissing-declarations -Wmissing-prototypes -Wnested-externs
-Wold-style-definition -Wpointer-arith -Wsign-compare
-Wstrict-prototypes -Wundef -Wwrite-strings -Wno-packed-not-aligned
-Wno-missing-field-initializers -D_GNU_SOURCE -fPIC
-march=armv8.2-a+crc+crypto+lse -DALLOW_EXPERIMENTAL_API
-DALLOW_INTERNAL_API -Wno-format-truncation -Wdisabled-optimization
-Waggregate-return -Wbad-function-cast -Wno-sign-compare
-Wno-unused-parameter -Wno-unused-variable -Wno-empty-body
-Wno-unused-but-set-variable -MD -MQ
'drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_bootcfg.c.o'
-MF 'drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_bootcfg.c.o.d'
-o 'drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_bootcfg.c.o'
-c ../../dpdk/drivers/common/sfc_efx/base/efx_bootcfg.c
In file included from ../../dpdk/lib/librte_eal/arm/include/rte_atomic.h:9,
                 from ../../dpdk/lib/librte_eal/include/generic/rte_pause.h:19,
                 from ../../dpdk/lib/librte_eal/arm/include/rte_pause_64.h:19,
                 from ../../dpdk/lib/librte_eal/arm/include/rte_pause.h:13,
                 from
../../dpdk/lib/librte_eal/include/generic/rte_spinlock.h:25,
                 from ../../dpdk/lib/librte_eal/arm/include/rte_spinlock.h:17,
                 from ../../dpdk/drivers/common/sfc_efx/efsys.h:15,
                 from ../../dpdk/drivers/common/sfc_efx/base/efx.h:11,
                 from ../../dpdk/drivers/common/sfc_efx/base/efx_bootcfg.c:7:
../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h: In function
‘__cas_128_relaxed’:
../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:81:20: error:
function returns an aggregate [-Werror=aggregate-return]
 __ATOMIC128_CAS_OP(__cas_128_relaxed, "casp")
...


-- 
David Marchand


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [dpdk-dev] [PATCH 1/2] eal/arm: fix gcc build for optimization level 0
  2020-11-27  9:45           ` David Marchand
@ 2020-11-27 10:05             ` Ruifeng Wang
  2020-11-27 10:28               ` Jerin Jacob
  0 siblings, 1 reply; 23+ messages in thread
From: Ruifeng Wang @ 2020-11-27 10:05 UTC (permalink / raw)
  To: David Marchand, Jerin Jacob
  Cc: Andrew Rybchenko, jerinj, Honnappa Nagarahalli, dev, nd, Feifei Wang, nd

> -----Original Message-----
> From: David Marchand <david.marchand@redhat.com>
> Sent: Friday, November 27, 2020 5:45 PM
> To: Jerin Jacob <jerinjacobk@gmail.com>
> Cc: Ruifeng Wang <Ruifeng.Wang@arm.com>; Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru>; jerinj@marvell.com; Honnappa
> Nagarahalli <Honnappa.Nagarahalli@arm.com>; dev <dev@dpdk.org>; nd
> <nd@arm.com>; Feifei Wang <Feifei.Wang2@arm.com>
> Subject: Re: [dpdk-dev] [PATCH 1/2] eal/arm: fix gcc build for optimization
> level 0
> 
> On Fri, Nov 27, 2020 at 10:34 AM Jerin Jacob <jerinjacobk@gmail.com> wrote:
> >
> > On Fri, Nov 27, 2020 at 2:56 PM David Marchand
> > <david.marchand@redhat.com> wrote:
> > >
> > > On Fri, Nov 27, 2020 at 9:51 AM Jerin Jacob <jerinjacobk@gmail.com>
> wrote:
> > > >
> > > > On Fri, Nov 27, 2020 at 2:09 PM David Marchand
> > > > <david.marchand@redhat.com> wrote:
> > > > >
> > > > > On Fri, Nov 27, 2020 at 9:10 AM Ruifeng Wang
> <ruifeng.wang@arm.com> wrote:
> > > > > >
> > > > > > Gcc build with '-O0' on platforms with
> RTE_ARM_FEATURE_ATOMICS
> > > > > > set failed for:
> > > > > >  ../lib/librte_efd/rte_efd.c
> > > > > >  Assembler messages:
> > > > > > 3866: Error: selected processor does not support `crc32cb w0,w0,w1'
> > > > > > 3890: Error: selected processor does not support `crc32ch w0,w0,w1'
> > > > > > 3914: Error: selected processor does not support `crc32cw
> w0,w0,w1'
> > > > > > 3938: Error: selected processor does not support `crc32cx w0,w0,x1'
> > > > > >
> > > > > > This was caused by an architecture specifier added for Clang.
> > > > > > Unlike Clang, Gcc considers each inline assembly block to be
> > > > > > dependent and therefor, the architecture specifier impacts
> > > > > > assemble of some blocks require certain extension support.
> > > > >
> > > > > I reproduced this error with -O0 for
> config/arm/arm64_octeontx2_linux_gcc.
> > > > > The patch looks simple enough and it only affects ARM builds.
> > > > >
> > > > > Jerin,
> > > > > Are you okay with this change for 20.11?
> > > > > Or should we wait 21.02?
> > > >
> > > > I could reproduce the issue with meson  build -Dbuildtype=debug
> > > > --cross-file config/arm/arm64_octeontx2_linux_gcc
> > > >
> > > > This fix is OK. Request to merge for 20.11
> > > >
> > > > Acked-by: Jerin Jacob <jerinj@marvell.com>
> > >
> > > Ruifeng, Andrew,
> > >
> > > I get a compilation error with this patch on sfc using gcc and
> > > config/arm/arm64_octeontx2_linux_gcc config + --buildtype=debug
> > > and/or
> > > -Dc_args=-O0 .
> > >
> > > aarch64-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture
> > > 8.2-2019.01 (arm-rel-8.28)) 8.2.1 20180802
> > >
> > > FAILED:
> > > drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_crc32.c.o
> > > aarch64-linux-gnu-gcc
> > > -Idrivers/common/sfc_efx/base/932d09a@@sfc_base@sta
> > > -Idrivers/common/sfc_efx/base
> > > -I../../dpdk/drivers/common/sfc_efx/base
> > > -Idrivers/common/sfc_efx -I../../dpdk/drivers/common/sfc_efx -I.
> > > -I../../dpdk/ -Iconfig -I../../dpdk/config -Ilib/librte_eal/include
> > > -I../../dpdk/lib/librte_eal/include -Ilib/librte_eal/linux/include
> > > -I../../dpdk/lib/librte_eal/linux/include
> > > -Ilib/librte_eal/arm/include -I../../dpdk/lib/librte_eal/arm/include
> > > -Ilib/librte_eal/common -I../../dpdk/lib/librte_eal/common
> > > -Ilib/librte_eal -I../../dpdk/lib/librte_eal -Ilib/librte_kvargs
> > > -I../../dpdk/lib/librte_kvargs
> > > -Ilib/librte_telemetry/../librte_metrics
> > > -I../../dpdk/lib/librte_telemetry/../librte_metrics
> > > -Ilib/librte_telemetry -I../../dpdk/lib/librte_telemetry
> > > -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall
> > > -Winvalid-pch -Werror -g -include rte_config.h -Wextra -Wcast-qual
> > > -Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security
> > > -Wmissing-declarations -Wmissing-prototypes -Wnested-externs
> > > -Wold-style-definition -Wpointer-arith -Wsign-compare
> > > -Wstrict-prototypes -Wundef -Wwrite-strings -Wno-packed-not-aligned
> > > -Wno-missing-field-initializers -D_GNU_SOURCE -fPIC
> > > -march=armv8.2-a+crc+crypto+lse -DALLOW_EXPERIMENTAL_API
> > > -DALLOW_INTERNAL_API -Wno-format-truncation -Wdisabled-
> optimization
> > > -Waggregate-return -Wbad-function-cast -Wno-sign-compare
> > > -Wno-unused-parameter -Wno-unused-variable -Wno-empty-body
> > > -Wno-unused-but-set-variable -MD -MQ
> > > 'drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_crc32.c.o'
> > > -MF
> > >
> 'drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_crc32.c.o.d'
> > > -o
> 'drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_crc32.c.o'
> > > -c ../../dpdk/drivers/common/sfc_efx/base/efx_crc32.c
> > > In file included from ../../dpdk/lib/librte_eal/arm/include/rte_atomic.h:9,
> > >                  from ../../dpdk/lib/librte_eal/include/generic/rte_pause.h:19,
> > >                  from ../../dpdk/lib/librte_eal/arm/include/rte_pause_64.h:19,
> > >                  from ../../dpdk/lib/librte_eal/arm/include/rte_pause.h:13,
> > >                  from
> > > ../../dpdk/lib/librte_eal/include/generic/rte_spinlock.h:25,
> > >                  from ../../dpdk/lib/librte_eal/arm/include/rte_spinlock.h:17,
> > >                  from ../../dpdk/drivers/common/sfc_efx/efsys.h:15,
> > >                  from ../../dpdk/drivers/common/sfc_efx/base/efx.h:11,
> > >                  from ../../dpdk/drivers/common/sfc_efx/base/efx_crc32.c:7:
> > > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h: In function
> > > ‘__cas_128_relaxed’:
> > > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:81:20: error:
> > > function returns an aggregate [-Werror=aggregate-return]
> > > __ATOMIC128_CAS_OP(__cas_128_relaxed, "casp")
> > >                     ^~~~~~~~~~~~~~~~~
> > > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:57:1: note: in
> > > definition of macro ‘__ATOMIC128_CAS_OP’
> > >  cas_op_name(rte_int128_t *dst, rte_int128_t old, rte_int128_t updated)
> \
> > >  ^~~~~~~~~~~
> > > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h: In function
> > > ‘__cas_128_acquire’:
> > > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:82:20: error:
> > > function returns an aggregate [-Werror=aggregate-return]
> > > __ATOMIC128_CAS_OP(__cas_128_acquire, "caspa")
> > >                     ^~~~~~~~~~~~~~~~~
> > > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:57:1: note: in
> > > definition of macro ‘__ATOMIC128_CAS_OP’
> > >  cas_op_name(rte_int128_t *dst, rte_int128_t old, rte_int128_t updated)
> \
> > >  ^~~~~~~~~~~
> > > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h: In function
> > > ‘__cas_128_release’:
> > > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:83:20: error:
> > > function returns an aggregate [-Werror=aggregate-return]
> > > __ATOMIC128_CAS_OP(__cas_128_release, "caspl")
> > >                     ^~~~~~~~~~~~~~~~~
> > > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:57:1: note: in
> > > definition of macro ‘__ATOMIC128_CAS_OP’
> > >  cas_op_name(rte_int128_t *dst, rte_int128_t old, rte_int128_t updated)
> \
> > >  ^~~~~~~~~~~
> > > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h: In function
> > > ‘__cas_128_acq_rel’:
> > > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:84:20: error:
> > > function returns an aggregate [-Werror=aggregate-return]
> > > __ATOMIC128_CAS_OP(__cas_128_acq_rel, "caspal")
> > >                     ^~~~~~~~~~~~~~~~~
> > > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:57:1: note: in
> > > definition of macro ‘__ATOMIC128_CAS_OP’
> > >  cas_op_name(rte_int128_t *dst, rte_int128_t old, rte_int128_t updated)
> \
> > >  ^~~~~~~~~~~
> > > cc1: all warnings being treated as errors
> > >
> > >
> > > If I waive those warnings:
> > > - next to fail is net/igc (fixed by next patch so ok)
> > > - and then next to fail is net/sfc.
> >
> > Regarding the net/sfc build, Could try clean build.(I got the warning
> > first, after the clean build, it is OK)
> 
> That's what I first thought too, then I noticed that test-meson-builds.sh had
> switched back my build dir to debugoptimized.
> 
> 
> From scratch:
> 
> The Meson build system
> Version: 0.52.0
> Source dir: /home/dmarchan/dpdk
> Build dir: /home/dmarchan/builds/build-arm64-octeontx2
> Build type: cross build
> Program cat found: YES (/usr/bin/cat)
> Project name: DPDK
> Project version: 20.11.0-rc5
> Appending CFLAGS from environment: '-Werror'
> C compiler for the build machine: ccache gcc (gcc 9.3.1 "gcc (GCC)
> 9.3.1 20200408 (Red Hat 9.3.1-2)")
> C linker for the build machine: GNU ld.bfd 2.32-33 C compiler for the host
> machine: aarch64-linux-gnu-gcc (gcc 8.2.1 "aarch64-linux-gnu-gcc (GNU
> Toolchain for the A-profile Architecture
> 8.2-2019.01 (arm-rel-8.28)) 8.2.1 20180802") C linker for the host machine:
> GNU ld.bfd 8.2-2019 Build machine cpu family: x86_64 Build machine cpu:
> x86_64 Host machine cpu family: aarch64 Host machine cpu: armv8-a Target
> machine cpu family: aarch64 Target machine cpu: armv8-a ...
> Option buildtype is: debug [default: release] Option default_library is: shared
> [default: static] Found ninja-1.9.0 at /usr/bin/ninja
> ninja: Entering directory `/home/dmarchan/builds/build-arm64-octeontx2'
> [479/2558] Compiling C object
> 'drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_bootcfg.c.o'.
> FAILED:
> drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_bootcfg.c.o
> aarch64-linux-gnu-gcc
> -Idrivers/common/sfc_efx/base/932d09a@@sfc_base@sta
> -Idrivers/common/sfc_efx/base -I../../dpdk/drivers/common/sfc_efx/base
> -Idrivers/common/sfc_efx -I../../dpdk/drivers/common/sfc_efx -I.
> -I../../dpdk/ -Iconfig -I../../dpdk/config -Ilib/librte_eal/include -
> I../../dpdk/lib/librte_eal/include -Ilib/librte_eal/linux/include -
> I../../dpdk/lib/librte_eal/linux/include -Ilib/librte_eal/arm/include -
> I../../dpdk/lib/librte_eal/arm/include -Ilib/librte_eal/common -
> I../../dpdk/lib/librte_eal/common -Ilib/librte_eal -I../../dpdk/lib/librte_eal -
> Ilib/librte_kvargs -I../../dpdk/lib/librte_kvargs -
> Ilib/librte_telemetry/../librte_metrics
> -I../../dpdk/lib/librte_telemetry/../librte_metrics
> -Ilib/librte_telemetry -I../../dpdk/lib/librte_telemetry -fdiagnostics-
> color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Werror -g -
> include rte_config.h -Wextra -Wcast-qual -Wdeprecated -Wformat -
> Wformat-nonliteral -Wformat-security -Wmissing-declarations -Wmissing-
> prototypes -Wnested-externs -Wold-style-definition -Wpointer-arith -
> Wsign-compare -Wstrict-prototypes -Wundef -Wwrite-strings -Wno-packed-
> not-aligned -Wno-missing-field-initializers -D_GNU_SOURCE -fPIC -
> march=armv8.2-a+crc+crypto+lse -DALLOW_EXPERIMENTAL_API -
> DALLOW_INTERNAL_API -Wno-format-truncation -Wdisabled-optimization -
> Waggregate-return -Wbad-function-cast -Wno-sign-compare -Wno-unused-
> parameter -Wno-unused-variable -Wno-empty-body -Wno-unused-but-set-
> variable -MD -MQ
> 'drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_bootcfg.c.o'
> -MF
> 'drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_bootcfg.c.o.
> d'
> -o
> 'drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_bootcfg.c.o'
> -c ../../dpdk/drivers/common/sfc_efx/base/efx_bootcfg.c
> In file included from ../../dpdk/lib/librte_eal/arm/include/rte_atomic.h:9,
>                  from ../../dpdk/lib/librte_eal/include/generic/rte_pause.h:19,
>                  from ../../dpdk/lib/librte_eal/arm/include/rte_pause_64.h:19,
>                  from ../../dpdk/lib/librte_eal/arm/include/rte_pause.h:13,
>                  from
> ../../dpdk/lib/librte_eal/include/generic/rte_spinlock.h:25,
>                  from ../../dpdk/lib/librte_eal/arm/include/rte_spinlock.h:17,
>                  from ../../dpdk/drivers/common/sfc_efx/efsys.h:15,
>                  from ../../dpdk/drivers/common/sfc_efx/base/efx.h:11,
>                  from ../../dpdk/drivers/common/sfc_efx/base/efx_bootcfg.c:7:
> ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h: In function
> ‘__cas_128_relaxed’:
> ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:81:20: error:
> function returns an aggregate [-Werror=aggregate-return]
> __ATOMIC128_CAS_OP(__cas_128_relaxed, "casp") ...

I can see similar warning message (function returns an aggregate) when doing "-O0" build.
Since "-Werror=aggregate-return" is used, error will be reported.
This is because '__cas_128_xxx' return aggregated data type I think.
Inline the functions should resolve the issue. But it could cause register corruption as discussed
when the code was added:
http://patches.dpdk.org/patch/55580/

No quick solution I can think of.
> 
> 
> --
> David Marchand


^ permalink raw reply	[flat|nested] 23+ messages in thread

* [dpdk-dev] [PATCH v2 0/2] gcc build fix
  2020-11-27  8:09 [dpdk-dev] [PATCH 0/2] gcc build fix Ruifeng Wang
  2020-11-27  8:09 ` [dpdk-dev] [PATCH 1/2] eal/arm: fix gcc build for optimization level 0 Ruifeng Wang
  2020-11-27  8:09 ` [dpdk-dev] [PATCH 2/2] net/igc: " Ruifeng Wang
@ 2020-11-27 10:15 ` Ruifeng Wang
  2020-11-27 10:15   ` [dpdk-dev] [PATCH v2 1/2] eal/arm: fix gcc build for optimization level 0 Ruifeng Wang
                     ` (2 more replies)
  2020-11-27 16:03 ` [dpdk-dev] [PATCH " Thomas Monjalon
  3 siblings, 3 replies; 23+ messages in thread
From: Ruifeng Wang @ 2020-11-27 10:15 UTC (permalink / raw)
  Cc: dev, honnappa.nagarahalli, nd, Ruifeng Wang

This series fixed issues found when building project
with Gcc '-O0' option.

Ruifeng Wang (2):
  eal/arm: fix gcc build for optimization level 0
  net/igc: fix gcc build for optimization level 0

 drivers/net/igc/base/meson.build           | 3 ++-
 lib/librte_eal/arm/include/rte_atomic_64.h | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

-- 
2.20.1


^ permalink raw reply	[flat|nested] 23+ messages in thread

* [dpdk-dev] [PATCH v2 1/2] eal/arm: fix gcc build for optimization level 0
  2020-11-27 10:15 ` [dpdk-dev] [PATCH v2 0/2] gcc build fix Ruifeng Wang
@ 2020-11-27 10:15   ` Ruifeng Wang
  2020-11-27 13:03     ` Ruifeng Wang
  2020-11-27 10:15   ` [dpdk-dev] [PATCH v2 2/2] net/igc: " Ruifeng Wang
  2020-11-27 13:35   ` [dpdk-dev] [PATCH v2 0/2] gcc build fix Thomas Monjalon
  2 siblings, 1 reply; 23+ messages in thread
From: Ruifeng Wang @ 2020-11-27 10:15 UTC (permalink / raw)
  To: Jerin Jacob, Ruifeng Wang, Honnappa Nagarahalli; +Cc: dev, nd, Feifei Wang

Gcc build with '-O0' on platforms with RTE_ARM_FEATURE_ATOMICS set
failed for:
 ../lib/librte_efd/rte_efd.c
 Assembler messages:
3866: Error: selected processor does not support `crc32cb w0,w0,w1'
3890: Error: selected processor does not support `crc32ch w0,w0,w1'
3914: Error: selected processor does not support `crc32cw w0,w0,w1'
3938: Error: selected processor does not support `crc32cx w0,w0,x1'

This was caused by an architecture specifier added for Clang.
Unlike Clang, Gcc considers each inline assembly block to be dependent
and therefore, the architecture specifier impacts assemble of some
blocks require certain extension support.

Used arch_extension instead to not override architecture.
Referred for [1] to fix the issue.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=dd1f6308b28edf0452dd5dc7877992903ec61e69

Fixes: 8fce34cd0a6a ("eal/arm: fix clang build of native target")

Reported-by: Feifei Wang <feifei.wang2@arm.com>
Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
---
v2:
New approach to use arch_extension instead.

 lib/librte_eal/arm/include/rte_atomic_64.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/librte_eal/arm/include/rte_atomic_64.h b/lib/librte_eal/arm/include/rte_atomic_64.h
index 7fcd17466..6584bc38c 100644
--- a/lib/librte_eal/arm/include/rte_atomic_64.h
+++ b/lib/librte_eal/arm/include/rte_atomic_64.h
@@ -46,7 +46,7 @@ rte_atomic_thread_fence(int memorder)
 /*------------------------ 128 bit atomic operations -------------------------*/
 
 #if defined(__ARM_FEATURE_ATOMICS) || defined(RTE_ARM_FEATURE_ATOMICS)
-#define __LSE_PREAMBLE	".arch armv8-a+lse\n"
+#define __LSE_PREAMBLE	".arch_extension lse\n"
 
 #define __ATOMIC128_CAS_OP(cas_op_name, op_string)                          \
 static __rte_noinline rte_int128_t                                          \
-- 
2.20.1


^ permalink raw reply	[flat|nested] 23+ messages in thread

* [dpdk-dev] [PATCH v2 2/2] net/igc: fix gcc build for optimization level 0
  2020-11-27 10:15 ` [dpdk-dev] [PATCH v2 0/2] gcc build fix Ruifeng Wang
  2020-11-27 10:15   ` [dpdk-dev] [PATCH v2 1/2] eal/arm: fix gcc build for optimization level 0 Ruifeng Wang
@ 2020-11-27 10:15   ` Ruifeng Wang
  2020-11-27 13:35   ` [dpdk-dev] [PATCH v2 0/2] gcc build fix Thomas Monjalon
  2 siblings, 0 replies; 23+ messages in thread
From: Ruifeng Wang @ 2020-11-27 10:15 UTC (permalink / raw)
  To: Jeff Guo, Haiyue Wang, Alvin Zhang, Ferruh Yigit
  Cc: dev, honnappa.nagarahalli, nd, Ruifeng Wang, Feifei Wang, Jerin Jacob

Gcc build with '-O0' failed for:
 ../drivers/net/igc/base/igc_api.c
 Assembler messages:
29: Error: selected processor does not support `casp x0,x1,x2,x3,[x4]'
82: Error: selected processor does not support `caspa x0,x1,x2,x3,[x4]'
135: Error: selected processor does not support `caspl x0,x1,x2,x3,[x4]'
188: Error: selected processor does not support `caspal x0,x1,x2,x3,[x4]'

This is due to c_args not been passed to meson.

Fixes: 8cb7c57d9b3c ("net/igc: support device initialization")
Cc: alvinx.zhang@intel.com

Reported-by: Feifei Wang <feifei.wang2@arm.com>
Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
Tested-by: Jerin Jacob <jerinj@marvell.com>
---
 drivers/net/igc/base/meson.build | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/igc/base/meson.build b/drivers/net/igc/base/meson.build
index 299985180..690704fe0 100644
--- a/drivers/net/igc/base/meson.build
+++ b/drivers/net/igc/base/meson.build
@@ -13,6 +13,7 @@ sources = [
 ]
 
 base_lib = static_library('igc_base', sources,
-	dependencies: static_rte_eal)
+	dependencies: static_rte_eal,
+	c_args: cflags)
 
 base_objs = base_lib.extract_all_objects()
-- 
2.20.1


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [dpdk-dev] [PATCH 1/2] eal/arm: fix gcc build for optimization level 0
  2020-11-27 10:05             ` Ruifeng Wang
@ 2020-11-27 10:28               ` Jerin Jacob
  0 siblings, 0 replies; 23+ messages in thread
From: Jerin Jacob @ 2020-11-27 10:28 UTC (permalink / raw)
  To: Ruifeng Wang
  Cc: David Marchand, Andrew Rybchenko, jerinj, Honnappa Nagarahalli,
	dev, nd, Feifei Wang

On Fri, Nov 27, 2020 at 3:35 PM Ruifeng Wang <Ruifeng.Wang@arm.com> wrote:
>
> > -----Original Message-----
> > From: David Marchand <david.marchand@redhat.com>
> > Sent: Friday, November 27, 2020 5:45 PM
> > To: Jerin Jacob <jerinjacobk@gmail.com>
> > Cc: Ruifeng Wang <Ruifeng.Wang@arm.com>; Andrew Rybchenko
> > <andrew.rybchenko@oktetlabs.ru>; jerinj@marvell.com; Honnappa
> > Nagarahalli <Honnappa.Nagarahalli@arm.com>; dev <dev@dpdk.org>; nd
> > <nd@arm.com>; Feifei Wang <Feifei.Wang2@arm.com>
> > Subject: Re: [dpdk-dev] [PATCH 1/2] eal/arm: fix gcc build for optimization
> > level 0
> >
> > On Fri, Nov 27, 2020 at 10:34 AM Jerin Jacob <jerinjacobk@gmail.com> wrote:
> > >
> > > On Fri, Nov 27, 2020 at 2:56 PM David Marchand
> > > <david.marchand@redhat.com> wrote:
> > > >
> > > > On Fri, Nov 27, 2020 at 9:51 AM Jerin Jacob <jerinjacobk@gmail.com>
> > wrote:
> > > > >
> > > > > On Fri, Nov 27, 2020 at 2:09 PM David Marchand
> > > > > <david.marchand@redhat.com> wrote:
> > > > > >
> > > > > > On Fri, Nov 27, 2020 at 9:10 AM Ruifeng Wang
> > <ruifeng.wang@arm.com> wrote:
> > > > > > >
> > > > > > > Gcc build with '-O0' on platforms with
> > RTE_ARM_FEATURE_ATOMICS
> > > > > > > set failed for:
> > > > > > >  ../lib/librte_efd/rte_efd.c
> > > > > > >  Assembler messages:
> > > > > > > 3866: Error: selected processor does not support `crc32cb w0,w0,w1'
> > > > > > > 3890: Error: selected processor does not support `crc32ch w0,w0,w1'
> > > > > > > 3914: Error: selected processor does not support `crc32cw
> > w0,w0,w1'
> > > > > > > 3938: Error: selected processor does not support `crc32cx w0,w0,x1'
> > > > > > >
> > > > > > > This was caused by an architecture specifier added for Clang.
> > > > > > > Unlike Clang, Gcc considers each inline assembly block to be
> > > > > > > dependent and therefor, the architecture specifier impacts
> > > > > > > assemble of some blocks require certain extension support.
> > > > > >
> > > > > > I reproduced this error with -O0 for
> > config/arm/arm64_octeontx2_linux_gcc.
> > > > > > The patch looks simple enough and it only affects ARM builds.
> > > > > >
> > > > > > Jerin,
> > > > > > Are you okay with this change for 20.11?
> > > > > > Or should we wait 21.02?
> > > > >
> > > > > I could reproduce the issue with meson  build -Dbuildtype=debug
> > > > > --cross-file config/arm/arm64_octeontx2_linux_gcc
> > > > >
> > > > > This fix is OK. Request to merge for 20.11
> > > > >
> > > > > Acked-by: Jerin Jacob <jerinj@marvell.com>
> > > >
> > > > Ruifeng, Andrew,
> > > >
> > > > I get a compilation error with this patch on sfc using gcc and
> > > > config/arm/arm64_octeontx2_linux_gcc config + --buildtype=debug
> > > > and/or
> > > > -Dc_args=-O0 .
> > > >
> > > > aarch64-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture
> > > > 8.2-2019.01 (arm-rel-8.28)) 8.2.1 20180802
> > > >
> > > > FAILED:
> > > > drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_crc32.c.o
> > > > aarch64-linux-gnu-gcc
> > > > -Idrivers/common/sfc_efx/base/932d09a@@sfc_base@sta
> > > > -Idrivers/common/sfc_efx/base
> > > > -I../../dpdk/drivers/common/sfc_efx/base
> > > > -Idrivers/common/sfc_efx -I../../dpdk/drivers/common/sfc_efx -I.
> > > > -I../../dpdk/ -Iconfig -I../../dpdk/config -Ilib/librte_eal/include
> > > > -I../../dpdk/lib/librte_eal/include -Ilib/librte_eal/linux/include
> > > > -I../../dpdk/lib/librte_eal/linux/include
> > > > -Ilib/librte_eal/arm/include -I../../dpdk/lib/librte_eal/arm/include
> > > > -Ilib/librte_eal/common -I../../dpdk/lib/librte_eal/common
> > > > -Ilib/librte_eal -I../../dpdk/lib/librte_eal -Ilib/librte_kvargs
> > > > -I../../dpdk/lib/librte_kvargs
> > > > -Ilib/librte_telemetry/../librte_metrics
> > > > -I../../dpdk/lib/librte_telemetry/../librte_metrics
> > > > -Ilib/librte_telemetry -I../../dpdk/lib/librte_telemetry
> > > > -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall
> > > > -Winvalid-pch -Werror -g -include rte_config.h -Wextra -Wcast-qual
> > > > -Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security
> > > > -Wmissing-declarations -Wmissing-prototypes -Wnested-externs
> > > > -Wold-style-definition -Wpointer-arith -Wsign-compare
> > > > -Wstrict-prototypes -Wundef -Wwrite-strings -Wno-packed-not-aligned
> > > > -Wno-missing-field-initializers -D_GNU_SOURCE -fPIC
> > > > -march=armv8.2-a+crc+crypto+lse -DALLOW_EXPERIMENTAL_API
> > > > -DALLOW_INTERNAL_API -Wno-format-truncation -Wdisabled-
> > optimization
> > > > -Waggregate-return -Wbad-function-cast -Wno-sign-compare
> > > > -Wno-unused-parameter -Wno-unused-variable -Wno-empty-body
> > > > -Wno-unused-but-set-variable -MD -MQ
> > > > 'drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_crc32.c.o'
> > > > -MF
> > > >
> > 'drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_crc32.c.o.d'
> > > > -o
> > 'drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_crc32.c.o'
> > > > -c ../../dpdk/drivers/common/sfc_efx/base/efx_crc32.c
> > > > In file included from ../../dpdk/lib/librte_eal/arm/include/rte_atomic.h:9,
> > > >                  from ../../dpdk/lib/librte_eal/include/generic/rte_pause.h:19,
> > > >                  from ../../dpdk/lib/librte_eal/arm/include/rte_pause_64.h:19,
> > > >                  from ../../dpdk/lib/librte_eal/arm/include/rte_pause.h:13,
> > > >                  from
> > > > ../../dpdk/lib/librte_eal/include/generic/rte_spinlock.h:25,
> > > >                  from ../../dpdk/lib/librte_eal/arm/include/rte_spinlock.h:17,
> > > >                  from ../../dpdk/drivers/common/sfc_efx/efsys.h:15,
> > > >                  from ../../dpdk/drivers/common/sfc_efx/base/efx.h:11,
> > > >                  from ../../dpdk/drivers/common/sfc_efx/base/efx_crc32.c:7:
> > > > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h: In function
> > > > ‘__cas_128_relaxed’:
> > > > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:81:20: error:
> > > > function returns an aggregate [-Werror=aggregate-return]
> > > > __ATOMIC128_CAS_OP(__cas_128_relaxed, "casp")
> > > >                     ^~~~~~~~~~~~~~~~~
> > > > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:57:1: note: in
> > > > definition of macro ‘__ATOMIC128_CAS_OP’
> > > >  cas_op_name(rte_int128_t *dst, rte_int128_t old, rte_int128_t updated)
> > \
> > > >  ^~~~~~~~~~~
> > > > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h: In function
> > > > ‘__cas_128_acquire’:
> > > > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:82:20: error:
> > > > function returns an aggregate [-Werror=aggregate-return]
> > > > __ATOMIC128_CAS_OP(__cas_128_acquire, "caspa")
> > > >                     ^~~~~~~~~~~~~~~~~
> > > > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:57:1: note: in
> > > > definition of macro ‘__ATOMIC128_CAS_OP’
> > > >  cas_op_name(rte_int128_t *dst, rte_int128_t old, rte_int128_t updated)
> > \
> > > >  ^~~~~~~~~~~
> > > > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h: In function
> > > > ‘__cas_128_release’:
> > > > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:83:20: error:
> > > > function returns an aggregate [-Werror=aggregate-return]
> > > > __ATOMIC128_CAS_OP(__cas_128_release, "caspl")
> > > >                     ^~~~~~~~~~~~~~~~~
> > > > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:57:1: note: in
> > > > definition of macro ‘__ATOMIC128_CAS_OP’
> > > >  cas_op_name(rte_int128_t *dst, rte_int128_t old, rte_int128_t updated)
> > \
> > > >  ^~~~~~~~~~~
> > > > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h: In function
> > > > ‘__cas_128_acq_rel’:
> > > > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:84:20: error:
> > > > function returns an aggregate [-Werror=aggregate-return]
> > > > __ATOMIC128_CAS_OP(__cas_128_acq_rel, "caspal")
> > > >                     ^~~~~~~~~~~~~~~~~
> > > > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:57:1: note: in
> > > > definition of macro ‘__ATOMIC128_CAS_OP’
> > > >  cas_op_name(rte_int128_t *dst, rte_int128_t old, rte_int128_t updated)
> > \
> > > >  ^~~~~~~~~~~
> > > > cc1: all warnings being treated as errors
> > > >
> > > >
> > > > If I waive those warnings:
> > > > - next to fail is net/igc (fixed by next patch so ok)
> > > > - and then next to fail is net/sfc.
> > >
> > > Regarding the net/sfc build, Could try clean build.(I got the warning
> > > first, after the clean build, it is OK)
> >
> > That's what I first thought too, then I noticed that test-meson-builds.sh had
> > switched back my build dir to debugoptimized.
> >
> >
> > From scratch:
> >
> > The Meson build system
> > Version: 0.52.0
> > Source dir: /home/dmarchan/dpdk
> > Build dir: /home/dmarchan/builds/build-arm64-octeontx2
> > Build type: cross build
> > Program cat found: YES (/usr/bin/cat)
> > Project name: DPDK
> > Project version: 20.11.0-rc5
> > Appending CFLAGS from environment: '-Werror'
> > C compiler for the build machine: ccache gcc (gcc 9.3.1 "gcc (GCC)
> > 9.3.1 20200408 (Red Hat 9.3.1-2)")
> > C linker for the build machine: GNU ld.bfd 2.32-33 C compiler for the host
> > machine: aarch64-linux-gnu-gcc (gcc 8.2.1 "aarch64-linux-gnu-gcc (GNU
> > Toolchain for the A-profile Architecture
> > 8.2-2019.01 (arm-rel-8.28)) 8.2.1 20180802") C linker for the host machine:
> > GNU ld.bfd 8.2-2019 Build machine cpu family: x86_64 Build machine cpu:
> > x86_64 Host machine cpu family: aarch64 Host machine cpu: armv8-a Target
> > machine cpu family: aarch64 Target machine cpu: armv8-a ...
> > Option buildtype is: debug [default: release] Option default_library is: shared
> > [default: static] Found ninja-1.9.0 at /usr/bin/ninja
> > ninja: Entering directory `/home/dmarchan/builds/build-arm64-octeontx2'
> > [479/2558] Compiling C object
> > 'drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_bootcfg.c.o'.
> > FAILED:
> > drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_bootcfg.c.o
> > aarch64-linux-gnu-gcc
> > -Idrivers/common/sfc_efx/base/932d09a@@sfc_base@sta
> > -Idrivers/common/sfc_efx/base -I../../dpdk/drivers/common/sfc_efx/base
> > -Idrivers/common/sfc_efx -I../../dpdk/drivers/common/sfc_efx -I.
> > -I../../dpdk/ -Iconfig -I../../dpdk/config -Ilib/librte_eal/include -
> > I../../dpdk/lib/librte_eal/include -Ilib/librte_eal/linux/include -
> > I../../dpdk/lib/librte_eal/linux/include -Ilib/librte_eal/arm/include -
> > I../../dpdk/lib/librte_eal/arm/include -Ilib/librte_eal/common -
> > I../../dpdk/lib/librte_eal/common -Ilib/librte_eal -I../../dpdk/lib/librte_eal -
> > Ilib/librte_kvargs -I../../dpdk/lib/librte_kvargs -
> > Ilib/librte_telemetry/../librte_metrics
> > -I../../dpdk/lib/librte_telemetry/../librte_metrics
> > -Ilib/librte_telemetry -I../../dpdk/lib/librte_telemetry -fdiagnostics-
> > color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Werror -g -
> > include rte_config.h -Wextra -Wcast-qual -Wdeprecated -Wformat -
> > Wformat-nonliteral -Wformat-security -Wmissing-declarations -Wmissing-
> > prototypes -Wnested-externs -Wold-style-definition -Wpointer-arith -
> > Wsign-compare -Wstrict-prototypes -Wundef -Wwrite-strings -Wno-packed-
> > not-aligned -Wno-missing-field-initializers -D_GNU_SOURCE -fPIC -
> > march=armv8.2-a+crc+crypto+lse -DALLOW_EXPERIMENTAL_API -
> > DALLOW_INTERNAL_API -Wno-format-truncation -Wdisabled-optimization -
> > Waggregate-return -Wbad-function-cast -Wno-sign-compare -Wno-unused-
> > parameter -Wno-unused-variable -Wno-empty-body -Wno-unused-but-set-
> > variable -MD -MQ
> > 'drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_bootcfg.c.o'
> > -MF
> > 'drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_bootcfg.c.o.
> > d'
> > -o
> > 'drivers/common/sfc_efx/base/932d09a@@sfc_base@sta/efx_bootcfg.c.o'
> > -c ../../dpdk/drivers/common/sfc_efx/base/efx_bootcfg.c
> > In file included from ../../dpdk/lib/librte_eal/arm/include/rte_atomic.h:9,
> >                  from ../../dpdk/lib/librte_eal/include/generic/rte_pause.h:19,
> >                  from ../../dpdk/lib/librte_eal/arm/include/rte_pause_64.h:19,
> >                  from ../../dpdk/lib/librte_eal/arm/include/rte_pause.h:13,
> >                  from
> > ../../dpdk/lib/librte_eal/include/generic/rte_spinlock.h:25,
> >                  from ../../dpdk/lib/librte_eal/arm/include/rte_spinlock.h:17,
> >                  from ../../dpdk/drivers/common/sfc_efx/efsys.h:15,
> >                  from ../../dpdk/drivers/common/sfc_efx/base/efx.h:11,
> >                  from ../../dpdk/drivers/common/sfc_efx/base/efx_bootcfg.c:7:
> > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h: In function
> > ‘__cas_128_relaxed’:
> > ../../dpdk/lib/librte_eal/arm/include/rte_atomic_64.h:81:20: error:
> > function returns an aggregate [-Werror=aggregate-return]
> > __ATOMIC128_CAS_OP(__cas_128_relaxed, "casp") ...
>
> I can see similar warning message (function returns an aggregate) when doing "-O0" build.
> Since "-Werror=aggregate-return" is used, error will be reported.
> This is because '__cas_128_xxx' return aggregated data type I think.
> Inline the functions should resolve the issue. But it could cause register corruption as discussed
> when the code was added:
> http://patches.dpdk.org/patch/55580/
>
> No quick solution I can think of.

Yes. We may need to return two separate uint64_t by taking as the pointer.
It will be NOT a candidate for 20.11.

In my setup:
meson --buildtype=debug build --cross-file config/arm/arm64_octeontx2_linux_gcc
ninja -C build

Shows the warnings for "warning: function returns an aggregate
[-Waggregate-return]", Since
warning not treated as the error it links.
I think, for this release, The current[1] minor changes are OK as it
improves the situation.
http://patches.dpdk.org/project/dpdk/list/?submitter=Ruifeng








> >
> >
> > --
> > David Marchand
>

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [dpdk-dev] [PATCH 2/2] net/igc: fix gcc build for optimization level 0
  2020-11-27  9:02   ` David Marchand
@ 2020-11-27 12:13     ` David Marchand
  2020-11-27 14:50       ` Wang, Haiyue
  0 siblings, 1 reply; 23+ messages in thread
From: David Marchand @ 2020-11-27 12:13 UTC (permalink / raw)
  To: Bruce Richardson, Yigit, Ferruh
  Cc: Jeff Guo, Haiyue Wang, Alvin Zhang, dev, Honnappa Nagarahalli,
	nd, Ruifeng Wang, Feifei Wang

On Fri, Nov 27, 2020 at 10:02 AM David Marchand
<david.marchand@redhat.com> wrote:
>
> On Fri, Nov 27, 2020 at 9:10 AM Ruifeng Wang <ruifeng.wang@arm.com> wrote:
> >
> > Gcc build with '-O0' failed for:
> >  ../drivers/net/igc/base/igc_api.c
> >  Assembler messages:
> > 29: Error: selected processor does not support `casp x0,x1,x2,x3,[x4]'
> > 82: Error: selected processor does not support `caspa x0,x1,x2,x3,[x4]'
> > 135: Error: selected processor does not support `caspl x0,x1,x2,x3,[x4]'
> > 188: Error: selected processor does not support `caspal x0,x1,x2,x3,[x4]'
> >
> > This is due to c_args not been passed to meson.
> >
> > Fixes: 8cb7c57d9b3c ("net/igc: support device initialization")
> > Cc: alvinx.zhang@intel.com
> >
> > Reported-by: Feifei Wang <feifei.wang2@arm.com>
> > Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
>
> I did not get to reproduce it yet (get an error on first patch...).
>
> The patch looks fine but I fear some compilation problems since a lot
> of base drivers filter cflags.
> Still waiting for CI results...
>
> Bruce,Ferruh,
> Wdyt?

Comparing before/after patch on x86, gcc, static build, the only difference is:
 -march=native -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API
-Wno-format-truncation

Which corresponds to drivers/meson.build:

default_cflags = machine_args
default_cflags += ['-DALLOW_EXPERIMENTAL_API']
default_cflags += ['-DALLOW_INTERNAL_API']

if cc.has_argument('-Wno-format-truncation')
        default_cflags += '-Wno-format-truncation'
endif

So little risk wrt warning flags.
Still I'd like to hear from Intel, thanks.


-- 
David Marchand


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [dpdk-dev] [PATCH v2 1/2] eal/arm: fix gcc build for optimization level 0
  2020-11-27 10:15   ` [dpdk-dev] [PATCH v2 1/2] eal/arm: fix gcc build for optimization level 0 Ruifeng Wang
@ 2020-11-27 13:03     ` Ruifeng Wang
  0 siblings, 0 replies; 23+ messages in thread
From: Ruifeng Wang @ 2020-11-27 13:03 UTC (permalink / raw)
  To: Ruifeng Wang, jerinj, Honnappa Nagarahalli; +Cc: dev, nd, Feifei Wang, nd

> -----Original Message-----
> From: Ruifeng Wang <ruifeng.wang@arm.com>
> Sent: Friday, November 27, 2020 6:15 PM
> To: jerinj@marvell.com; Ruifeng Wang <Ruifeng.Wang@arm.com>;
> Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> Cc: dev@dpdk.org; nd <nd@arm.com>; Feifei Wang
> <Feifei.Wang2@arm.com>
> Subject: [PATCH v2 1/2] eal/arm: fix gcc build for optimization level 0
> 
> Gcc build with '-O0' on platforms with RTE_ARM_FEATURE_ATOMICS set
> failed for:
>  ../lib/librte_efd/rte_efd.c
>  Assembler messages:
> 3866: Error: selected processor does not support `crc32cb w0,w0,w1'
> 3890: Error: selected processor does not support `crc32ch w0,w0,w1'
> 3914: Error: selected processor does not support `crc32cw w0,w0,w1'
> 3938: Error: selected processor does not support `crc32cx w0,w0,x1'
> 
> This was caused by an architecture specifier added for Clang.
> Unlike Clang, Gcc considers each inline assembly block to be dependent and
> therefore, the architecture specifier impacts assemble of some blocks
> require certain extension support.
> 
> Used arch_extension instead to not override architecture.
> Referred for [1] to fix the issue.
> 
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i
> d=dd1f6308b28edf0452dd5dc7877992903ec61e69
> 
> Fixes: 8fce34cd0a6a ("eal/arm: fix clang build of native target")
> 
> Reported-by: Feifei Wang <feifei.wang2@arm.com>
> Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
> ---
> v2:
> New approach to use arch_extension instead.
> 
>  lib/librte_eal/arm/include/rte_atomic_64.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/librte_eal/arm/include/rte_atomic_64.h
> b/lib/librte_eal/arm/include/rte_atomic_64.h
> index 7fcd17466..6584bc38c 100644
> --- a/lib/librte_eal/arm/include/rte_atomic_64.h
> +++ b/lib/librte_eal/arm/include/rte_atomic_64.h
> @@ -46,7 +46,7 @@ rte_atomic_thread_fence(int memorder)
>  /*------------------------ 128 bit atomic operations -------------------------*/
> 
>  #if defined(__ARM_FEATURE_ATOMICS) ||
> defined(RTE_ARM_FEATURE_ATOMICS)
> -#define __LSE_PREAMBLE	".arch armv8-a+lse\n"
> +#define __LSE_PREAMBLE	".arch_extension lse\n"

This approach has issue on earlier version Clang (eg. clang-6).
I think it is better to take approach in v1.
> 
>  #define __ATOMIC128_CAS_OP(cas_op_name, op_string)                          \
>  static __rte_noinline rte_int128_t                                          \
> --
> 2.20.1


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [dpdk-dev] [PATCH v2 0/2] gcc build fix
  2020-11-27 10:15 ` [dpdk-dev] [PATCH v2 0/2] gcc build fix Ruifeng Wang
  2020-11-27 10:15   ` [dpdk-dev] [PATCH v2 1/2] eal/arm: fix gcc build for optimization level 0 Ruifeng Wang
  2020-11-27 10:15   ` [dpdk-dev] [PATCH v2 2/2] net/igc: " Ruifeng Wang
@ 2020-11-27 13:35   ` Thomas Monjalon
  2020-11-27 14:08     ` Ruifeng Wang
  2 siblings, 1 reply; 23+ messages in thread
From: Thomas Monjalon @ 2020-11-27 13:35 UTC (permalink / raw)
  To: Ruifeng Wang
  Cc: dev, honnappa.nagarahalli, nd, jerinj, bruce.richardson,
	ferruh.yigit, Vimal Chungath, hemant.agrawal, konstantin.ananyev

27/11/2020 11:15, Ruifeng Wang:
> This series fixed issues found when building project
> with Gcc '-O0' option.
> 
> Ruifeng Wang (2):
>   eal/arm: fix gcc build for optimization level 0
>   net/igc: fix gcc build for optimization level 0

No comment on the v2?
Ruifeng, why nobody was Cc'ed? You don't want reviews?

I am not going to accept such last minute fix
if there is no strong proof this v2 is good.



^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [dpdk-dev] [PATCH v2 0/2] gcc build fix
  2020-11-27 13:35   ` [dpdk-dev] [PATCH v2 0/2] gcc build fix Thomas Monjalon
@ 2020-11-27 14:08     ` Ruifeng Wang
  0 siblings, 0 replies; 23+ messages in thread
From: Ruifeng Wang @ 2020-11-27 14:08 UTC (permalink / raw)
  To: thomas
  Cc: dev, Honnappa Nagarahalli, nd, jerinj, bruce.richardson,
	ferruh.yigit, Vimal Chungath, hemant.agrawal, konstantin.ananyev,
	nd

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Friday, November 27, 2020 9:36 PM
> To: Ruifeng Wang <Ruifeng.Wang@arm.com>
> Cc: dev@dpdk.org; Honnappa Nagarahalli
> <Honnappa.Nagarahalli@arm.com>; nd <nd@arm.com>; jerinj@marvell.com;
> bruce.richardson@intel.com; ferruh.yigit@intel.com; Vimal Chungath
> <vcchunga@amazon.com>; hemant.agrawal@nxp.com;
> konstantin.ananyev@intel.com
> Subject: Re: [dpdk-dev] [PATCH v2 0/2] gcc build fix
> 
> 27/11/2020 11:15, Ruifeng Wang:
> > This series fixed issues found when building project with Gcc '-O0'
> > option.
> >
> > Ruifeng Wang (2):
> >   eal/arm: fix gcc build for optimization level 0
> >   net/igc: fix gcc build for optimization level 0
> 
> No comment on the v2?
> Ruifeng, why nobody was Cc'ed? You don't want reviews?

Just used get-maintainer.sh to get Cc list. I should have added more people.
> 
> I am not going to accept such last minute fix if there is no strong proof this v2
> is good.

v2 1/2 patch has issue on earlier version Clang (eg. clang-6).
I think we should continue with v1 approach.
> 


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [dpdk-dev] [PATCH 2/2] net/igc: fix gcc build for optimization level 0
  2020-11-27 12:13     ` David Marchand
@ 2020-11-27 14:50       ` Wang, Haiyue
  0 siblings, 0 replies; 23+ messages in thread
From: Wang, Haiyue @ 2020-11-27 14:50 UTC (permalink / raw)
  To: David Marchand, Richardson, Bruce, Yigit, Ferruh
  Cc: Guo, Jia, Zhang, AlvinX, dev, Honnappa Nagarahalli, nd,
	Ruifeng Wang, Feifei Wang

> -----Original Message-----
> From: David Marchand <david.marchand@redhat.com>
> Sent: Friday, November 27, 2020 20:14
> To: Richardson, Bruce <bruce.richardson@intel.com>; Yigit, Ferruh <ferruh.yigit@intel.com>
> Cc: Guo, Jia <jia.guo@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>; Zhang, AlvinX
> <alvinx.zhang@intel.com>; dev <dev@dpdk.org>; Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>; nd
> <nd@arm.com>; Ruifeng Wang <ruifeng.wang@arm.com>; Feifei Wang <feifei.wang2@arm.com>
> Subject: Re: [dpdk-dev] [PATCH 2/2] net/igc: fix gcc build for optimization level 0
> 
> On Fri, Nov 27, 2020 at 10:02 AM David Marchand
> <david.marchand@redhat.com> wrote:
> >
> > On Fri, Nov 27, 2020 at 9:10 AM Ruifeng Wang <ruifeng.wang@arm.com> wrote:
> > >
> > > Gcc build with '-O0' failed for:
> > >  ../drivers/net/igc/base/igc_api.c
> > >  Assembler messages:
> > > 29: Error: selected processor does not support `casp x0,x1,x2,x3,[x4]'
> > > 82: Error: selected processor does not support `caspa x0,x1,x2,x3,[x4]'
> > > 135: Error: selected processor does not support `caspl x0,x1,x2,x3,[x4]'
> > > 188: Error: selected processor does not support `caspal x0,x1,x2,x3,[x4]'
> > >
> > > This is due to c_args not been passed to meson.
> > >
> > > Fixes: 8cb7c57d9b3c ("net/igc: support device initialization")
> > > Cc: alvinx.zhang@intel.com
> > >
> > > Reported-by: Feifei Wang <feifei.wang2@arm.com>
> > > Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
> >
> > I did not get to reproduce it yet (get an error on first patch...).
> >
> > The patch looks fine but I fear some compilation problems since a lot
> > of base drivers filter cflags.
> > Still waiting for CI results...
> >
> > Bruce,Ferruh,
> > Wdyt?
> 
> Comparing before/after patch on x86, gcc, static build, the only difference is:
>  -march=native -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API
> -Wno-format-truncation
> 
> Which corresponds to drivers/meson.build:
> 
> default_cflags = machine_args
> default_cflags += ['-DALLOW_EXPERIMENTAL_API']
> default_cflags += ['-DALLOW_INTERNAL_API']
> 
> if cc.has_argument('-Wno-format-truncation')
>         default_cflags += '-Wno-format-truncation'
> endif
> 
> So little risk wrt warning flags.
> Still I'd like to hear from Intel, thanks.
> 
> 

LGTM, after reading other Intel PMDs base meson design.

Acked-by: Haiyue Wang <haiyue.wang@intel.com>

> --
> David Marchand


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [dpdk-dev] [PATCH 0/2] gcc build fix
  2020-11-27  8:09 [dpdk-dev] [PATCH 0/2] gcc build fix Ruifeng Wang
                   ` (2 preceding siblings ...)
  2020-11-27 10:15 ` [dpdk-dev] [PATCH v2 0/2] gcc build fix Ruifeng Wang
@ 2020-11-27 16:03 ` Thomas Monjalon
  3 siblings, 0 replies; 23+ messages in thread
From: Thomas Monjalon @ 2020-11-27 16:03 UTC (permalink / raw)
  To: Ruifeng Wang
  Cc: dev, honnappa.nagarahalli, nd, Haiyue Wang, jerinj, stable,
	david.marchand

27/11/2020 09:09, Ruifeng Wang:
> This series fixed issues found when building project
> with Gcc '-O0' option.
> 
> Ruifeng Wang (2):
>   eal/arm: fix gcc build for optimization level 0
>   net/igc: fix gcc build for optimization level 0

Series v1 applied with Cc:stable, thanks.



^ permalink raw reply	[flat|nested] 23+ messages in thread

end of thread, other threads:[~2020-11-27 16:03 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-27  8:09 [dpdk-dev] [PATCH 0/2] gcc build fix Ruifeng Wang
2020-11-27  8:09 ` [dpdk-dev] [PATCH 1/2] eal/arm: fix gcc build for optimization level 0 Ruifeng Wang
2020-11-27  8:39   ` David Marchand
2020-11-27  8:51     ` Jerin Jacob
2020-11-27  9:25       ` David Marchand
2020-11-27  9:33         ` Jerin Jacob
2020-11-27  9:45           ` David Marchand
2020-11-27 10:05             ` Ruifeng Wang
2020-11-27 10:28               ` Jerin Jacob
2020-11-27  9:39         ` Andrew Rybchenko
2020-11-27  9:36     ` Ruifeng Wang
2020-11-27  8:09 ` [dpdk-dev] [PATCH 2/2] net/igc: " Ruifeng Wang
2020-11-27  8:53   ` Jerin Jacob
2020-11-27  9:02   ` David Marchand
2020-11-27 12:13     ` David Marchand
2020-11-27 14:50       ` Wang, Haiyue
2020-11-27 10:15 ` [dpdk-dev] [PATCH v2 0/2] gcc build fix Ruifeng Wang
2020-11-27 10:15   ` [dpdk-dev] [PATCH v2 1/2] eal/arm: fix gcc build for optimization level 0 Ruifeng Wang
2020-11-27 13:03     ` Ruifeng Wang
2020-11-27 10:15   ` [dpdk-dev] [PATCH v2 2/2] net/igc: " Ruifeng Wang
2020-11-27 13:35   ` [dpdk-dev] [PATCH v2 0/2] gcc build fix Thomas Monjalon
2020-11-27 14:08     ` Ruifeng Wang
2020-11-27 16:03 ` [dpdk-dev] [PATCH " Thomas Monjalon

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git