[v2] acl: fix build with gcc 11

Message ID 20210426133519.4777-1-konstantin.ananyev@intel.com (mailing list archive)
State Accepted, archived
Delegated to: Thomas Monjalon
Headers
Series [v2] acl: fix build with gcc 11 |

Checks

Context Check Description
ci/checkpatch warning coding style issues
ci/iol-intel-Functional success Functional Testing PASS
ci/iol-intel-Performance success Performance Testing PASS
ci/Intel-compilation success Compilation OK
ci/intel-Testing success Testing PASS
ci/github-robot success github build: passed
ci/iol-abi-testing success Testing PASS
ci/iol-testing success Testing PASS
ci/iol-mellanox-Performance success Performance Testing PASS

Commit Message

Ananyev, Konstantin April 26, 2021, 1:35 p.m. UTC
  gcc 11 with '-O2' complains about some variables being used without
being initialized:

In file included from ../lib/librte_acl/acl_run_avx512x8.h:201,
                 from ../lib/librte_acl/acl_run_avx512.c:110:
In function ‘start_flow_avx512x8’,
    inlined from ‘search_trie_avx512x8.constprop’ at ../lib/librte_acl/acl_run_avx512_common.h:317:2:
../lib/librte_acl/acl_run_avx512_common.h:210:13: warning: ‘pdata’ is used uninitialized [-Wuninitialized]
In file included from ../lib/librte_acl/acl_run_avx512x8.h:201,
                 from ../lib/librte_acl/acl_run_avx512.c:110:
../lib/librte_acl/acl_run_avx512_common.h: In function ‘search_trie_avx512x8.constprop’:
../lib/librte_acl/acl_run_avx512_common.h:314:32: note: ‘pdata’ declared here
In file included from ../lib/librte_acl/acl_run_avx512x8.h:201,
                 from ../lib/librte_acl/acl_run_avx512.c:110:
....

Indeed, these variables are not explicitly initialized,
but this is done intentionally.
We rely on constant mask value that we pass to start_flow*() functions
as a parameter to mask out uninitialized values.
Note that '-O3' doesn't produce this warning.
Anyway, to support clean build with gcc-11 this patch adds
explicit initialization for these variables.
I checked the output binary: with '-O3' both clang and gcc 10/11
generate no extra code for it.
Also performance test didn't reveal any regressions.

Bugzilla ID: 673
Fixes: b64c2295f7fc ("acl: add 256-bit AVX512 classify method")
Fixes: 45da22e42ec3 ("acl: add 512-bit AVX512 classify method")
Cc: stable@dpdk.org

Reported-by: Ali Alnubani <alialnu@nvidia.com>
Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
---
v2: update commit log
---
 lib/acl/acl_run_avx512_common.h | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)
  

Comments

Ali Alnubani April 26, 2021, 3:24 p.m. UTC | #1
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Konstantin Ananyev
> Sent: Monday, April 26, 2021 4:35 PM
> To: dev@dpdk.org
> Cc: Konstantin Ananyev <konstantin.ananyev@intel.com>; stable@dpdk.org
> Subject: [dpdk-dev] [PATCH v2] acl: fix build with gcc 11
> 

Thanks Konstantin, I don't see the acl build failures with this patch.
Tested with: meson --werror --buildtype=debugoptimized build && ninja -C build
I see now new build errors in net/tap, test/test_cryptodev, and app/test-pmd. I'll open separate issues for these.

Regards,
Ali
  
Kevin Traynor April 26, 2021, 3:30 p.m. UTC | #2
On 26/04/2021 16:24, Ali Alnubani wrote:
>> -----Original Message-----
>> From: dev <dev-bounces@dpdk.org> On Behalf Of Konstantin Ananyev
>> Sent: Monday, April 26, 2021 4:35 PM
>> To: dev@dpdk.org
>> Cc: Konstantin Ananyev <konstantin.ananyev@intel.com>; stable@dpdk.org
>> Subject: [dpdk-dev] [PATCH v2] acl: fix build with gcc 11
>>
> 
> Thanks Konstantin, I don't see the acl build failures with this patch.
> Tested with: meson --werror --buildtype=debugoptimized build && ninja -C build
> I see now new build errors in net/tap, test/test_cryptodev, and app/test-pmd. I'll open separate issues for these.
> 

Hi Ali,

There is already a Bz for test_cryptodev:
https://bugs.dpdk.org/show_bug.cgi?id=676

Kevin.

> Regards,
> Ali
>
  
Ali Alnubani April 26, 2021, 3:43 p.m. UTC | #3
> -----Original Message-----
> From: Kevin Traynor <ktraynor@redhat.com>
> Sent: Monday, April 26, 2021 6:31 PM
> To: Ali Alnubani <alialnu@nvidia.com>; Konstantin Ananyev
> <konstantin.ananyev@intel.com>; dev@dpdk.org
> Cc: stable@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2] acl: fix build with gcc 11
> 
> On 26/04/2021 16:24, Ali Alnubani wrote:
> >> -----Original Message-----
> >> From: dev <dev-bounces@dpdk.org> On Behalf Of Konstantin Ananyev
> >> Sent: Monday, April 26, 2021 4:35 PM
> >> To: dev@dpdk.org
> >> Cc: Konstantin Ananyev <konstantin.ananyev@intel.com>;
> >> stable@dpdk.org
> >> Subject: [dpdk-dev] [PATCH v2] acl: fix build with gcc 11
> >>
> >
> > Thanks Konstantin, I don't see the acl build failures with this patch.
> > Tested with: meson --werror --buildtype=debugoptimized build && ninja
> > -C build I see now new build errors in net/tap, test/test_cryptodev, and
> app/test-pmd. I'll open separate issues for these.
> >
> 
> Hi Ali,
> 
> There is already a Bz for test_cryptodev:
> https://bugs.dpdk.org/show_bug.cgi?id=676
> 

I opened the following 2 issues:
tap build failures on Fedora 35 with gcc 11 (https://bugs.dpdk.org/show_bug.cgi?id=690)
test-pmd build failure on Fedora 35 with gcc 11 (https://bugs.dpdk.org/show_bug.cgi?id=691)

Regards,
Ali
  
Thomas Monjalon May 5, 2021, 10:13 a.m. UTC | #4
26/04/2021 15:35, Konstantin Ananyev:
> gcc 11 with '-O2' complains about some variables being used without
> being initialized:
> 
> In file included from ../lib/librte_acl/acl_run_avx512x8.h:201,
>                  from ../lib/librte_acl/acl_run_avx512.c:110:
> In function ‘start_flow_avx512x8’,
>     inlined from ‘search_trie_avx512x8.constprop’ at ../lib/librte_acl/acl_run_avx512_common.h:317:2:
> ../lib/librte_acl/acl_run_avx512_common.h:210:13: warning: ‘pdata’ is used uninitialized [-Wuninitialized]
> In file included from ../lib/librte_acl/acl_run_avx512x8.h:201,
>                  from ../lib/librte_acl/acl_run_avx512.c:110:
> ../lib/librte_acl/acl_run_avx512_common.h: In function ‘search_trie_avx512x8.constprop’:
> ../lib/librte_acl/acl_run_avx512_common.h:314:32: note: ‘pdata’ declared here
> In file included from ../lib/librte_acl/acl_run_avx512x8.h:201,
>                  from ../lib/librte_acl/acl_run_avx512.c:110:
> ....
> 
> Indeed, these variables are not explicitly initialized,
> but this is done intentionally.
> We rely on constant mask value that we pass to start_flow*() functions
> as a parameter to mask out uninitialized values.
> Note that '-O3' doesn't produce this warning.
> Anyway, to support clean build with gcc-11 this patch adds
> explicit initialization for these variables.
> I checked the output binary: with '-O3' both clang and gcc 10/11
> generate no extra code for it.
> Also performance test didn't reveal any regressions.
> 
> Bugzilla ID: 673
> Fixes: b64c2295f7fc ("acl: add 256-bit AVX512 classify method")
> Fixes: 45da22e42ec3 ("acl: add 512-bit AVX512 classify method")
> Cc: stable@dpdk.org
> 
> Reported-by: Ali Alnubani <alialnu@nvidia.com>
> Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>

Applied, thanks
  

Patch

diff --git a/lib/acl/acl_run_avx512_common.h b/lib/acl/acl_run_avx512_common.h
index fafaf591e..fbad74d45 100644
--- a/lib/acl/acl_run_avx512_common.h
+++ b/lib/acl/acl_run_avx512_common.h
@@ -303,6 +303,28 @@  _F_(match_check_process)(struct acl_flow_avx512 *flow, uint32_t fm[2],
 	}
 }
 
+static inline void
+_F_(reset_flow_vars)(_T_simd di[2], _T_simd idx[2], _T_simd pdata[4],
+	_T_simd tr_lo[2], _T_simd tr_hi[2])
+{
+	di[0] = _M_SI_(setzero)();
+	di[1] = _M_SI_(setzero)();
+
+	idx[0] = _M_SI_(setzero)();
+	idx[1] = _M_SI_(setzero)();
+
+	pdata[0] = _M_SI_(setzero)();
+	pdata[1] = _M_SI_(setzero)();
+	pdata[2] = _M_SI_(setzero)();
+	pdata[3] = _M_SI_(setzero)();
+
+	tr_lo[0] = _M_SI_(setzero)();
+	tr_lo[1] = _M_SI_(setzero)();
+
+	tr_hi[0] = _M_SI_(setzero)();
+	tr_hi[1] = _M_SI_(setzero)();
+}
+
 /*
  * Perform search for up to (2 * _N_) flows in parallel.
  * Use two sets of metadata, each serves _N_ flows max.
@@ -313,6 +335,8 @@  _F_(search_trie)(struct acl_flow_avx512 *flow)
 	uint32_t fm[2];
 	_T_simd di[2], idx[2], in[2], pdata[4], tr_lo[2], tr_hi[2];
 
+	_F_(reset_flow_vars)(di, idx, pdata, tr_lo, tr_hi);
+
 	/* first 1B load */
 	_F_(start_flow)(flow, _SIMD_MASK_BIT_, _SIMD_MASK_MAX_,
 			&pdata[0], &idx[0], &di[0]);