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
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
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 >
>> 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
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
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.
>> 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
>>> 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
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.
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
> 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
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