Ok. Thanks, Kyrill From: Christophe Lyon <christophe.l...@linaro.org> Sent: Tuesday, May 30, 2023 4:44 PM To: Kyrylo Tkachov <kyrylo.tkac...@arm.com> Cc: gcc-patches@gcc.gnu.org; Stam Markianos-Wright <stam.markianos-wri...@arm.com> Subject: Re: [PATCH] [arm] testsuite: make mve_intrinsic_type_overloads-int.c libc-agnostic
Ping? On Tue, 23 May 2023 at 16:59, Stamatis Markianos-Wright <stam.markianos-wri...@arm.com<mailto:stam.markianos-wri...@arm.com>> wrote: On 23/05/2023 15:41, Christophe Lyon wrote: > Glibc defines int32_t as 'int' while newlib defines it as 'long int'. > > Although these correspond to the same size, g++ complains when using the > > > > > 'wrong' version: > invalid conversion from 'long int*' to 'int32_t*' {aka 'int*'} > [-fpermissive] > or > invalid conversion from 'int*' to 'int32_t*' {aka 'long int*'} > [-fpermissive] > > when calling vst1q(int32*, int32x4_t) with a first parameter of type > 'long int *' (resp. 'int *') > > To make this test pass with any type of toolchain, this patch defines > 'word_type' according to which libc is in use. Thank you for spotting this! I think this fix is needed on all of GCC12,13,trunk btw (it should apply cleanly) > > 2023-05-23 Christophe Lyon > <christophe.l...@linaro.org<mailto:christophe.l...@linaro.org>> > > gcc/testsuite/ > * gcc.target/arm/mve/intrinsics/mve_intrinsic_type_overloads-int.c: > Support both definitions of int32_t. > --- > .../mve_intrinsic_type_overloads-int.c | 28 ++++++++++--------- > 1 file changed, 15 insertions(+), 13 deletions(-) > > diff --git > a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_intrinsic_type_overloads-int.c > > b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_intrinsic_type_overloads-int.c > index 7947dc024bc..ab51cc8b323 100644 > --- > a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_intrinsic_type_overloads-int.c > +++ > b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_intrinsic_type_overloads-int.c > @@ -47,14 +47,22 @@ foo2 (short * addr, int16x8_t value) > vst1q (addr, value); > } > > -void > -foo3 (int * addr, int32x4_t value) > -{ > - vst1q (addr, value); /* { dg-warning "invalid conversion" "" { target c++ > } } */ > -} > +/* Glibc defines int32_t as 'int' while newlib defines it as 'long int'. > + > + Although these correspond to the same size, g++ complains when using the > + 'wrong' version: > + invalid conversion from 'long int*' to 'int32_t*' {aka 'int*'} > [-fpermissive] > + > + The trick below is to make this test pass whether using glibc-based or > + newlib-based toolchains. */ > > +#if defined(__GLIBC__) > +#define word_type int > +#else > +#define word_type long int > +#endif > void > -foo4 (long * addr, int32x4_t value) > +foo3 (word_type * addr, int32x4_t value) > { > vst1q (addr, value); > } > @@ -78,13 +86,7 @@ foo7 (unsigned short * addr, uint16x8_t value) > } > > void > -foo8 (unsigned int * addr, uint32x4_t value) > -{ > - vst1q (addr, value); /* { dg-warning "invalid conversion" "" { target c++ > } } */ > -} > - > -void > -foo9 (unsigned long * addr, uint32x4_t value) > +foo8 (unsigned word_type * addr, uint32x4_t value) > { > vst1q (addr, value); > }
