public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH] [arm] testsuite: make mve_intrinsic_type_overloads-int.c libc-agnostic
@ 2023-05-23 14:41 Christophe Lyon
  2023-05-23 14:59 ` Stamatis Markianos-Wright
  2023-12-06 16:37 ` Richard Earnshaw
  0 siblings, 2 replies; 5+ messages in thread
From: Christophe Lyon @ 2023-05-23 14:41 UTC (permalink / raw)
  To: gcc-patches, stam.markianos-wright, Kyrylo.Tkachov; +Cc: Christophe Lyon

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


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

* Re: [PATCH] [arm] testsuite: make mve_intrinsic_type_overloads-int.c libc-agnostic
  2023-05-23 14:41 [PATCH] [arm] testsuite: make mve_intrinsic_type_overloads-int.c libc-agnostic Christophe Lyon
@ 2023-05-23 14:59 ` Stamatis Markianos-Wright
  2023-05-30 15:43   ` Christophe Lyon
  2023-12-06 16:37 ` Richard Earnshaw
  1 sibling, 1 reply; 5+ messages in thread
From: Stamatis Markianos-Wright @ 2023-05-23 14:59 UTC (permalink / raw)
  To: Christophe Lyon, gcc-patches, Kyrylo.Tkachov


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

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

* Re: [PATCH] [arm] testsuite: make mve_intrinsic_type_overloads-int.c libc-agnostic
  2023-05-23 14:59 ` Stamatis Markianos-Wright
@ 2023-05-30 15:43   ` Christophe Lyon
  2023-05-30 15:44     ` Kyrylo Tkachov
  0 siblings, 1 reply; 5+ messages in thread
From: Christophe Lyon @ 2023-05-30 15:43 UTC (permalink / raw)
  To: kyrylo.tkachov; +Cc: gcc-patches, Stamatis Markianos-Wright

[-- Attachment #1: Type: text/plain, Size: 3026 bytes --]

Ping?


On Tue, 23 May 2023 at 16:59, Stamatis Markianos-Wright <
stam.markianos-wright@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.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
> >   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);
> >   }
>

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

* RE: [PATCH] [arm] testsuite: make mve_intrinsic_type_overloads-int.c libc-agnostic
  2023-05-30 15:43   ` Christophe Lyon
@ 2023-05-30 15:44     ` Kyrylo Tkachov
  0 siblings, 0 replies; 5+ messages in thread
From: Kyrylo Tkachov @ 2023-05-30 15:44 UTC (permalink / raw)
  To: Christophe Lyon; +Cc: gcc-patches, Stam Markianos-Wright

[-- Attachment #1: Type: text/plain, Size: 3632 bytes --]

Ok.
Thanks,
Kyrill

From: Christophe Lyon <christophe.lyon@linaro.org>
Sent: Tuesday, May 30, 2023 4:44 PM
To: Kyrylo Tkachov <Kyrylo.Tkachov@arm.com>
Cc: gcc-patches@gcc.gnu.org; Stam Markianos-Wright <Stam.Markianos-Wright@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-wright@arm.com<mailto:stam.markianos-wright@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.lyon@linaro.org<mailto: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
>   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);
>   }

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

* Re: [PATCH] [arm] testsuite: make mve_intrinsic_type_overloads-int.c libc-agnostic
  2023-05-23 14:41 [PATCH] [arm] testsuite: make mve_intrinsic_type_overloads-int.c libc-agnostic Christophe Lyon
  2023-05-23 14:59 ` Stamatis Markianos-Wright
@ 2023-12-06 16:37 ` Richard Earnshaw
  1 sibling, 0 replies; 5+ messages in thread
From: Richard Earnshaw @ 2023-12-06 16:37 UTC (permalink / raw)
  To: Christophe Lyon, gcc-patches, stam.markianos-wright, Kyrylo.Tkachov

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.

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

end of thread, other threads:[~2023-12-06 16:37 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-05-23 14:41 [PATCH] [arm] testsuite: make mve_intrinsic_type_overloads-int.c libc-agnostic Christophe Lyon
2023-05-23 14:59 ` Stamatis Markianos-Wright
2023-05-30 15:43   ` Christophe Lyon
2023-05-30 15:44     ` Kyrylo Tkachov
2023-12-06 16:37 ` Richard Earnshaw

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 read-only IMAP folder(s) and NNTP newsgroup(s).