Re: [PATCH] [arm] testsuite: make mve_intrinsic_type_overloads-int.c libc-agnostic

[Richard Earnshaw <Richard.Earnshaw@foss.arm.com>]

Sorry, I only just spotted this while looking at something else.


On 23/05/2023 15:41, Christophe Lyon via Gcc-patches 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.
> 
> 2023-05-23  Christophe Lyon  <christophe.lyon@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

GCC #defines __INT32_TYPE__ for this and should be more reliable than 
trying to detect one specific library implementation.  Did you try that?

>   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);
>   }

R.