* [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: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 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-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 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-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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).