DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] [PATCH] eal: fix rte_memcpy build on ppc with gcc 9.3
@ 2020-05-04 17:45 David Christensen
  2020-05-04 21:03 ` [dpdk-dev] [PATCH v2] " David Christensen
  0 siblings, 1 reply; 12+ messages in thread
From: David Christensen @ 2020-05-04 17:45 UTC (permalink / raw)
  To: dev; +Cc: David Christensen

Building DPDK on Ubuntu 20.04 with GCC 9.3.0 results in a "subscript is
outside array bounds" message in rte_memcpy function.  The build error
is caused by an interaction between __builtin_constant_p and
"-Werror=array-bounds" as described in this bugzilla:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90387

Modify the code to disable the array-bounds check for GCC versions 9.0
to 9.3.

Signed-off-by: David Christensen <drc@linux.vnet.ibm.com>
---
 lib/librte_eal/ppc/include/rte_memcpy.h | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/lib/librte_eal/ppc/include/rte_memcpy.h b/lib/librte_eal/ppc/include/rte_memcpy.h
index 25311ba1d..dce173d4b 100644
--- a/lib/librte_eal/ppc/include/rte_memcpy.h
+++ b/lib/librte_eal/ppc/include/rte_memcpy.h
@@ -8,8 +8,7 @@
 
 #include <stdint.h>
 #include <string.h>
-/*To include altivec.h, GCC version must  >= 4.8 */
-#include <altivec.h>
+#include "rte_altivec.h"
 
 #ifdef __cplusplus
 extern "C" {
@@ -17,6 +16,11 @@ extern "C" {
 
 #include "generic/rte_memcpy.h"
 
+#if (__GNUC__ == 9 && __GNUC_MINOR__ < 4)
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Warray-bounds"
+#endif
+
 static inline void
 rte_mov16(uint8_t *dst, const uint8_t *src)
 {
@@ -192,6 +196,10 @@ rte_memcpy_func(void *dst, const void *src, size_t n)
 	return ret;
 }
 
+#if (__GNUC__ == 9 && __GNUC_MINOR__ < 4)
+#pragma GCC diagnostic pop
+#endif
+
 #ifdef __cplusplus
 }
 #endif
-- 
2.18.1


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

* [dpdk-dev] [PATCH v2] eal: fix rte_memcpy build on ppc with gcc 9.3
  2020-05-04 17:45 [dpdk-dev] [PATCH] eal: fix rte_memcpy build on ppc with gcc 9.3 David Christensen
@ 2020-05-04 21:03 ` David Christensen
  2020-05-05 10:33   ` Ferruh Yigit
  2020-05-06 16:13   ` David Marchand
  0 siblings, 2 replies; 12+ messages in thread
From: David Christensen @ 2020-05-04 21:03 UTC (permalink / raw)
  To: dev; +Cc: David Christensen

Building DPDK on Ubuntu 20.04 with GCC 9.3.0 results in a "subscript is
outside array bounds" message in rte_memcpy function.  The build error
is caused by an interaction between __builtin_constant_p and
"-Werror=array-bounds" as described in this bugzilla:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90387

Modify the code to disable the array-bounds check for GCC versions 9.0
to 9.3.

Signed-off-by: David Christensen <drc@linux.vnet.ibm.com>
---

v2:
* Replace __GNUC__ and __GNUC_MINOR__ with GCC_VERSION
---
 lib/librte_eal/ppc/include/rte_memcpy.h | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/lib/librte_eal/ppc/include/rte_memcpy.h b/lib/librte_eal/ppc/include/rte_memcpy.h
index 25311ba1d..de47a5d2e 100644
--- a/lib/librte_eal/ppc/include/rte_memcpy.h
+++ b/lib/librte_eal/ppc/include/rte_memcpy.h
@@ -8,8 +8,8 @@
 
 #include <stdint.h>
 #include <string.h>
-/*To include altivec.h, GCC version must  >= 4.8 */
-#include <altivec.h>
+#include "rte_altivec.h"
+#include "rte_common.h"
 
 #ifdef __cplusplus
 extern "C" {
@@ -17,6 +17,11 @@ extern "C" {
 
 #include "generic/rte_memcpy.h"
 
+#if (GCC_VERSION >= 90000 && GCC_VERSION < 90400)
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Warray-bounds"
+#endif
+
 static inline void
 rte_mov16(uint8_t *dst, const uint8_t *src)
 {
@@ -192,6 +197,10 @@ rte_memcpy_func(void *dst, const void *src, size_t n)
 	return ret;
 }
 
+#if (GCC_VERSION >= 90000 && GCC_VERSION < 90400)
+#pragma GCC diagnostic pop
+#endif
+
 #ifdef __cplusplus
 }
 #endif
-- 
2.18.1


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

* Re: [dpdk-dev] [PATCH v2] eal: fix rte_memcpy build on ppc with gcc 9.3
  2020-05-04 21:03 ` [dpdk-dev] [PATCH v2] " David Christensen
@ 2020-05-05 10:33   ` Ferruh Yigit
  2020-05-05 16:32     ` David Christensen
  2020-05-06 16:13   ` David Marchand
  1 sibling, 1 reply; 12+ messages in thread
From: Ferruh Yigit @ 2020-05-05 10:33 UTC (permalink / raw)
  To: David Christensen, dev
  Cc: Michał Krawczyk, mw, Tzalik, Guy, Evgeny Schemeilin, igorch,
	Andrew Rybchenko

On 5/4/2020 10:03 PM, David Christensen wrote:
> Building DPDK on Ubuntu 20.04 with GCC 9.3.0 results in a "subscript is
> outside array bounds" message in rte_memcpy function.  The build error
> is caused by an interaction between __builtin_constant_p and
> "-Werror=array-bounds" as described in this bugzilla:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90387
> 
> Modify the code to disable the array-bounds check for GCC versions 9.0
> to 9.3.
> 
> Signed-off-by: David Christensen <drc@linux.vnet.ibm.com>
> ---
> 
> v2:
> * Replace __GNUC__ and __GNUC_MINOR__ with GCC_VERSION
> ---
>  lib/librte_eal/ppc/include/rte_memcpy.h | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/librte_eal/ppc/include/rte_memcpy.h b/lib/librte_eal/ppc/include/rte_memcpy.h
> index 25311ba1d..de47a5d2e 100644
> --- a/lib/librte_eal/ppc/include/rte_memcpy.h
> +++ b/lib/librte_eal/ppc/include/rte_memcpy.h
> @@ -8,8 +8,8 @@
>  
>  #include <stdint.h>
>  #include <string.h>
> -/*To include altivec.h, GCC version must  >= 4.8 */
> -#include <altivec.h>
> +#include "rte_altivec.h"
> +#include "rte_common.h"

I can't find "rte_altivec.h", am I missing something.

With just ignoring "-Warray-bounds" changes, I confirm ena build issue is fixed
with gcc 9.1

>  
>  #ifdef __cplusplus
>  extern "C" {
> @@ -17,6 +17,11 @@ extern "C" {
>  
>  #include "generic/rte_memcpy.h"
>  
> +#if (GCC_VERSION >= 90000 && GCC_VERSION < 90400)
> +#pragma GCC diagnostic push
> +#pragma GCC diagnostic ignored "-Warray-bounds"
> +#endif
> +
>  static inline void
>  rte_mov16(uint8_t *dst, const uint8_t *src)
>  {
> @@ -192,6 +197,10 @@ rte_memcpy_func(void *dst, const void *src, size_t n)
>  	return ret;
>  }
>  
> +#if (GCC_VERSION >= 90000 && GCC_VERSION < 90400)
> +#pragma GCC diagnostic pop
> +#endif
> +
>  #ifdef __cplusplus
>  }
>  #endif
> 


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

* Re: [dpdk-dev] [PATCH v2] eal: fix rte_memcpy build on ppc with gcc 9.3
  2020-05-05 10:33   ` Ferruh Yigit
@ 2020-05-05 16:32     ` David Christensen
  2020-05-05 16:41       ` David Marchand
  2020-05-05 18:42       ` Ferruh Yigit
  0 siblings, 2 replies; 12+ messages in thread
From: David Christensen @ 2020-05-05 16:32 UTC (permalink / raw)
  To: Ferruh Yigit, dev
  Cc: Michał Krawczyk, mw, Tzalik, Guy, Evgeny Schemeilin, igorch,
	Andrew Rybchenko



>> diff --git a/lib/librte_eal/ppc/include/rte_memcpy.h b/lib/librte_eal/ppc/include/rte_memcpy.h
>> index 25311ba1d..de47a5d2e 100644
>> --- a/lib/librte_eal/ppc/include/rte_memcpy.h
>> +++ b/lib/librte_eal/ppc/include/rte_memcpy.h
>> @@ -8,8 +8,8 @@
>>   
>>   #include <stdint.h>
>>   #include <string.h>
>> -/*To include altivec.h, GCC version must  >= 4.8 */
>> -#include <altivec.h>
>> +#include "rte_altivec.h"
>> +#include "rte_common.h"
> 
> I can't find "rte_altivec.h", am I missing something.
> 
> With just ignoring "-Warray-bounds" changes, I confirm ena build issue is fixed
> with gcc 9.1

The rte_altivec.h is related to another open patch required to build on 
POWER systems (http://patches.dpdk.org/patch/69605/) that's waiting to 
be accepted.  You may not have encountered it if you're not building the 
MLX5 PMD which has additional library requirements.

Dave

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

* Re: [dpdk-dev] [PATCH v2] eal: fix rte_memcpy build on ppc with gcc 9.3
  2020-05-05 16:32     ` David Christensen
@ 2020-05-05 16:41       ` David Marchand
  2020-05-05 20:28         ` David Christensen
  2020-05-05 18:42       ` Ferruh Yigit
  1 sibling, 1 reply; 12+ messages in thread
From: David Marchand @ 2020-05-05 16:41 UTC (permalink / raw)
  To: David Christensen
  Cc: Ferruh Yigit, dev, Michał Krawczyk, Marcin Wojtas, Tzalik,
	Guy, Evgeny Schemeilin, Igor Chauskin, Andrew Rybchenko

On Tue, May 5, 2020 at 6:32 PM David Christensen <drc@linux.vnet.ibm.com> wrote:
> >> diff --git a/lib/librte_eal/ppc/include/rte_memcpy.h b/lib/librte_eal/ppc/include/rte_memcpy.h
> >> index 25311ba1d..de47a5d2e 100644
> >> --- a/lib/librte_eal/ppc/include/rte_memcpy.h
> >> +++ b/lib/librte_eal/ppc/include/rte_memcpy.h
> >> @@ -8,8 +8,8 @@
> >>
> >>   #include <stdint.h>
> >>   #include <string.h>
> >> -/*To include altivec.h, GCC version must  >= 4.8 */
> >> -#include <altivec.h>
> >> +#include "rte_altivec.h"
> >> +#include "rte_common.h"
> >
> > I can't find "rte_altivec.h", am I missing something.
> >
> > With just ignoring "-Warray-bounds" changes, I confirm ena build issue is fixed
> > with gcc 9.1
>
> The rte_altivec.h is related to another open patch required to build on
> POWER systems (http://patches.dpdk.org/patch/69605/) that's waiting to
> be accepted.  You may not have encountered it if you're not building the
> MLX5 PMD which has additional library requirements.

Is there a point in having two patches?


-- 
David Marchand


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

* Re: [dpdk-dev] [PATCH v2] eal: fix rte_memcpy build on ppc with gcc 9.3
  2020-05-05 16:32     ` David Christensen
  2020-05-05 16:41       ` David Marchand
@ 2020-05-05 18:42       ` Ferruh Yigit
  2020-05-05 20:37         ` David Christensen
  1 sibling, 1 reply; 12+ messages in thread
From: Ferruh Yigit @ 2020-05-05 18:42 UTC (permalink / raw)
  To: David Christensen, dev
  Cc: Michał Krawczyk, mw, Tzalik, Guy, Evgeny Schemeilin, igorch,
	Andrew Rybchenko

On 5/5/2020 5:32 PM, David Christensen wrote:
> 
> 
>>> diff --git a/lib/librte_eal/ppc/include/rte_memcpy.h b/lib/librte_eal/ppc/include/rte_memcpy.h
>>> index 25311ba1d..de47a5d2e 100644
>>> --- a/lib/librte_eal/ppc/include/rte_memcpy.h
>>> +++ b/lib/librte_eal/ppc/include/rte_memcpy.h
>>> @@ -8,8 +8,8 @@
>>>   
>>>   #include <stdint.h>
>>>   #include <string.h>
>>> -/*To include altivec.h, GCC version must  >= 4.8 */
>>> -#include <altivec.h>
>>> +#include "rte_altivec.h"
>>> +#include "rte_common.h"
>>
>> I can't find "rte_altivec.h", am I missing something.
>>
>> With just ignoring "-Warray-bounds" changes, I confirm ena build issue is fixed
>> with gcc 9.1
> 
> The rte_altivec.h is related to another open patch required to build on 
> POWER systems (http://patches.dpdk.org/patch/69605/) that's waiting to 
> be accepted.  You may not have encountered it if you're not building the 
> MLX5 PMD which has additional library requirements.
> 

I see, I missed it. Looks good on top of that patch, although it still doesn't
apply cleanly.

It helps to put a comment to the patch about the dependent patch if it is not
merged yet.

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

* Re: [dpdk-dev] [PATCH v2] eal: fix rte_memcpy build on ppc with gcc 9.3
  2020-05-05 16:41       ` David Marchand
@ 2020-05-05 20:28         ` David Christensen
  2020-05-06  9:35           ` David Marchand
  0 siblings, 1 reply; 12+ messages in thread
From: David Christensen @ 2020-05-05 20:28 UTC (permalink / raw)
  To: David Marchand
  Cc: Ferruh Yigit, dev, Michał Krawczyk, Marcin Wojtas, Tzalik,
	Guy, Evgeny Schemeilin, Igor Chauskin, Andrew Rybchenko


>> The rte_altivec.h is related to another open patch required to build on
>> POWER systems (http://patches.dpdk.org/patch/69605/) that's waiting to
>> be accepted.  You may not have encountered it if you're not building the
>> MLX5 PMD which has additional library requirements.
> 
> Is there a point in having two patches?

The address different problems.  This patch addresses a build issue with 
gcc in Ubuntu 20.04, the other patch is related to the new trace library 
that uses boolean values from stdbool.h (or the use of the --std=c11 
build option) that causes a build error on POWER systems because of 
altivec definitions.

Dave

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

* Re: [dpdk-dev] [PATCH v2] eal: fix rte_memcpy build on ppc with gcc 9.3
  2020-05-05 18:42       ` Ferruh Yigit
@ 2020-05-05 20:37         ` David Christensen
  2020-05-06  9:23           ` Ferruh Yigit
  0 siblings, 1 reply; 12+ messages in thread
From: David Christensen @ 2020-05-05 20:37 UTC (permalink / raw)
  To: Ferruh Yigit, dev
  Cc: Michał Krawczyk, mw, Tzalik, Guy, Evgeny Schemeilin, igorch,
	Andrew Rybchenko

>>> I can't find "rte_altivec.h", am I missing something.
>>>
>>> With just ignoring "-Warray-bounds" changes, I confirm ena build issue is fixed
>>> with gcc 9.1
>>
>> The rte_altivec.h is related to another open patch required to build on
>> POWER systems (http://patches.dpdk.org/patch/69605/) that's waiting to
>> be accepted.  You may not have encountered it if you're not building the
>> MLX5 PMD which has additional library requirements.
>>
> 
> I see, I missed it. Looks good on top of that patch, although it still doesn't
> apply cleanly.
> 
> It helps to put a comment to the patch about the dependent patch if it is not
> merged yet.

It was an oversight on my part, forgetting that I had another patch 
installed.  I can submit a corrected version if you think it's necessary 
but then that that patch will have to be adjusted when it's eventually 
merged.  Sorry for the confusion.

Dave

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

* Re: [dpdk-dev] [PATCH v2] eal: fix rte_memcpy build on ppc with gcc 9.3
  2020-05-05 20:37         ` David Christensen
@ 2020-05-06  9:23           ` Ferruh Yigit
  0 siblings, 0 replies; 12+ messages in thread
From: Ferruh Yigit @ 2020-05-06  9:23 UTC (permalink / raw)
  To: David Christensen, dev, David Marchand
  Cc: Michał Krawczyk, mw, Tzalik, Guy, Evgeny Schemeilin, igorch,
	Andrew Rybchenko

On 5/5/2020 9:37 PM, David Christensen wrote:
>>>> I can't find "rte_altivec.h", am I missing something.
>>>>
>>>> With just ignoring "-Warray-bounds" changes, I confirm ena build issue is fixed
>>>> with gcc 9.1
>>>
>>> The rte_altivec.h is related to another open patch required to build on
>>> POWER systems (http://patches.dpdk.org/patch/69605/) that's waiting to
>>> be accepted.  You may not have encountered it if you're not building the
>>> MLX5 PMD which has additional library requirements.
>>>
>>
>> I see, I missed it. Looks good on top of that patch, although it still doesn't
>> apply cleanly.
>>
>> It helps to put a comment to the patch about the dependent patch if it is not
>> merged yet.
> 
> It was an oversight on my part, forgetting that I had another patch 
> installed.  I can submit a corrected version if you think it's necessary 
> but then that that patch will have to be adjusted when it's eventually 
> merged.  Sorry for the confusion.
> 

No worries, but I won't be merging the patches, it looks easy to manage the
conflict but eventually it is up to David to have a new version or not.


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

* Re: [dpdk-dev] [PATCH v2] eal: fix rte_memcpy build on ppc with gcc 9.3
  2020-05-05 20:28         ` David Christensen
@ 2020-05-06  9:35           ` David Marchand
  2020-05-06 15:59             ` David Christensen
  0 siblings, 1 reply; 12+ messages in thread
From: David Marchand @ 2020-05-06  9:35 UTC (permalink / raw)
  To: David Christensen
  Cc: Ferruh Yigit, dev, Michał Krawczyk, Marcin Wojtas, Tzalik,
	Guy, Evgeny Schemeilin, Igor Chauskin, Andrew Rybchenko

On Tue, May 5, 2020 at 10:28 PM David Christensen
<drc@linux.vnet.ibm.com> wrote:
>
>
> >> The rte_altivec.h is related to another open patch required to build on
> >> POWER systems (http://patches.dpdk.org/patch/69605/) that's waiting to
> >> be accepted.  You may not have encountered it if you're not building the
> >> MLX5 PMD which has additional library requirements.
> >
> > Is there a point in having two patches?
>
> The address different problems.  This patch addresses a build issue with
> gcc in Ubuntu 20.04, the other patch is related to the new trace library
> that uses boolean values from stdbool.h (or the use of the --std=c11
> build option) that causes a build error on POWER systems because of
> altivec definitions.

Ok, thanks.
WRT the conflict on the other ppc patch, no need for a new version.

Though it is probably worth backporting if it is a problem with gcc 9.x.
WDYT?
I can add a Cc: stable@dpdk.org when applying.


-- 
David Marchand


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

* Re: [dpdk-dev] [PATCH v2] eal: fix rte_memcpy build on ppc with gcc 9.3
  2020-05-06  9:35           ` David Marchand
@ 2020-05-06 15:59             ` David Christensen
  0 siblings, 0 replies; 12+ messages in thread
From: David Christensen @ 2020-05-06 15:59 UTC (permalink / raw)
  To: David Marchand
  Cc: Ferruh Yigit, dev, Michał Krawczyk, Marcin Wojtas, Tzalik,
	Guy, Evgeny Schemeilin, Igor Chauskin, Andrew Rybchenko

> Though it is probably worth backporting if it is a problem with gcc 9.x.
> WDYT?
> I can add a Cc: stable@dpdk.org when applying.

Agree, should be backported.

Dave

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

* Re: [dpdk-dev] [PATCH v2] eal: fix rte_memcpy build on ppc with gcc 9.3
  2020-05-04 21:03 ` [dpdk-dev] [PATCH v2] " David Christensen
  2020-05-05 10:33   ` Ferruh Yigit
@ 2020-05-06 16:13   ` David Marchand
  1 sibling, 0 replies; 12+ messages in thread
From: David Marchand @ 2020-05-06 16:13 UTC (permalink / raw)
  To: David Christensen; +Cc: dev

On Mon, May 4, 2020 at 11:04 PM David Christensen
<drc@linux.vnet.ibm.com> wrote:
>
> Building DPDK on Ubuntu 20.04 with GCC 9.3.0 results in a "subscript is
> outside array bounds" message in rte_memcpy function.  The build error
> is caused by an interaction between __builtin_constant_p and
> "-Werror=array-bounds" as described in this bugzilla:

Good to know, thanks.


> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90387
>
> Modify the code to disable the array-bounds check for GCC versions 9.0
> to 9.3.
>

Cc: stable@dpdk.org

> Signed-off-by: David Christensen <drc@linux.vnet.ibm.com>

Applied, thanks.


-- 
David Marchand


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

end of thread, other threads:[~2020-05-06 16:14 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-04 17:45 [dpdk-dev] [PATCH] eal: fix rte_memcpy build on ppc with gcc 9.3 David Christensen
2020-05-04 21:03 ` [dpdk-dev] [PATCH v2] " David Christensen
2020-05-05 10:33   ` Ferruh Yigit
2020-05-05 16:32     ` David Christensen
2020-05-05 16:41       ` David Marchand
2020-05-05 20:28         ` David Christensen
2020-05-06  9:35           ` David Marchand
2020-05-06 15:59             ` David Christensen
2020-05-05 18:42       ` Ferruh Yigit
2020-05-05 20:37         ` David Christensen
2020-05-06  9:23           ` Ferruh Yigit
2020-05-06 16:13   ` David Marchand

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