[PATCH 0/5][testsuite] Fixing testcases which fail with 16-bit int

[PATCH 0/5][testsuite] Fixing testcases which fail with 16-bit int

[Rask Ingemann Lambertsen]

   The five patch sets in this patch series fix a total of 60 testsuite
failures on m32c-unknown-elf. I have checked that they fix the failures they
are supposed to fix and that there are no new failures on
x86_64-unknown-linux-gnu. The patches are independent.

-- 
Rask Ingemann Lambertsen

[PATCH 5/5][testsuite] Use stdint.h when needing int of exact size

[Rask Ingemann Lambertsen]

   These testcases all rely on very specific integer sizes to pass. The
vector tests assume the vectors have exactly four elements and simd-4.c
additionally needs integers of exactly 32 bits and 64 bits. pr27743.c relies
on sign extension of bit 31, so a signed 32-bit integer is required. This
patch uses types from stdint.h to make sure that these requirements are
met, also on targets where int gives you only 16 bits.

   Ok for trunk?

:ADDPATCH testsuite:

2007-07-24  Rask Ingemann Lambertsen  <rask@sygehus.dk>

	* gcc.dg/torture/pr27743.c (bar): Use an integer of exactly 32 bits
	where required.
	* gcc.c-torture/execute/simd-1.c: Likewise.
	* gcc.c-torture/execute/pr23135.c: Likewise.
	* gcc.c-torture/execute/simd-4.c (__ev_convert_s64)(main): Likewise.
	Use an integer of exactly 64 bits where required.

Index: gcc.c-torture/execute/simd-1.c
===================================================================
--- gcc.c-torture/execute/simd-1.c	(revision 126653)
+++ gcc.c-torture/execute/simd-1.c	(working copy)
@@ -3,9 +3,10 @@
    Purpose: Test generic SIMD support.  This test should work
    regardless of if the target has SIMD instructions.
 */
+#include <stdint.h>
 
-typedef int __attribute__((vector_size (16))) vecint;
-typedef int __attribute__((mode(SI))) siint;
+typedef int32_t __attribute__((vector_size (16))) vecint;
+typedef int32_t siint;
 
 vecint i = { 150, 100, 150, 200 };
 vecint j = { 10, 13, 20, 30 };
Index: gcc.c-torture/execute/simd-4.c
===================================================================
--- gcc.c-torture/execute/simd-4.c	(revision 126653)
+++ gcc.c-torture/execute/simd-4.c	(working copy)
@@ -1,17 +1,18 @@
-typedef int __attribute__((vector_size(8))) v2si;
-long long s64;
+#include <stdint.h>
+typedef int32_t __attribute__((vector_size(8))) v2si;
+int64_t s64;
 
-static inline long long
+static inline int64_t
 __ev_convert_s64 (v2si a)
 {
-  return (long long) a;
+  return (int64_t) a;
 }
 
 int main()
 {
-  union { long long ll; int i[2]; } endianness_test;
+  union { int64_t ll; int32_t i[2]; } endianness_test;
   endianness_test.ll = 1;
-  int little_endian = endianness_test.i[0];
+  int32_t little_endian = endianness_test.i[0];
   s64 = __ev_convert_s64 ((v2si){1,0xffffffff});
   if (s64 != (little_endian ? 0xffffffff00000001LL : 0x1ffffffffLL))
     abort ();
Index: gcc.c-torture/execute/pr23135.c
===================================================================
--- gcc.c-torture/execute/pr23135.c	(revision 126653)
+++ gcc.c-torture/execute/pr23135.c	(working copy)
@@ -1,14 +1,15 @@
 /* Based on execute/simd-1.c, modified by joern.rennecke@st.com to
    trigger a reload bug.  Verified for gcc mainline from 20050722 13:00 UTC
    for sh-elf -m4 -O2.  */
+#include <stdint.h>
 #ifndef STACK_SIZE
 #define STACK_SIZE (256*1024)
 #endif
 
 typedef struct { char c[STACK_SIZE/2]; } big_t;
 
-typedef int __attribute__((vector_size (8))) vecint;
-typedef int __attribute__((mode(SI))) siint;
+typedef int32_t __attribute__((vector_size (8))) vecint;
+typedef int32_t siint;
 
 vecint i = { 150, 100 };
 vecint j = { 10, 13 };
Index: gcc.dg/torture/pr27743.c
===================================================================
--- gcc.dg/torture/pr27743.c	(revision 126653)
+++ gcc.dg/torture/pr27743.c	(working copy)
@@ -1,10 +1,11 @@
-/* { dg-do run } */
+/* { dg-do run { target { stdint_types } } } */
 
+#include <stdint.h>
 extern void abort(void);
 
-int bar(int a)
+int32_t bar (int32_t a)
 {
-  return ((unsigned) ((a) >> 2)) >> 15;
+  return ((uint32_t) ((a) >> 2)) >> 15;
 }
 
 int main()

-- 
Rask Ingemann Lambertsen

Re: [PATCH 5/5][testsuite] Use stdint.h when needing int of exact size

[Andrew Pinski]

On 7/24/07, Rask Ingemann Lambertsen <rask@sygehus.dk> wrote:
>    These testcases all rely on very specific integer sizes to pass. The
> vector tests assume the vectors have exactly four elements and simd-4.c
> additionally needs integers of exactly 32 bits and 64 bits. pr27743.c relies
> on sign extension of bit 31, so a signed 32-bit integer is required. This
> patch uses types from stdint.h to make sure that these requirements are
> met, also on targets where int gives you only 16 bits.
>
>    Ok for trunk?
>
> :ADDPATCH testsuite:
>
> 2007-07-24  Rask Ingemann Lambertsen  <rask@sygehus.dk>
>
>         * gcc.dg/torture/pr27743.c (bar): Use an integer of exactly 32 bits
>         where required.
>         * gcc.c-torture/execute/simd-1.c: Likewise.
>         * gcc.c-torture/execute/pr23135.c: Likewise.
>         * gcc.c-torture/execute/simd-4.c (__ev_convert_s64)(main): Likewise.
>         Use an integer of exactly 64 bits where required.

Why did you change the simd ones from using SImode?

Thanks,
Andrew Pinski

Re: [PATCH 5/5][testsuite] Use stdint.h when needing int of exact size

[Rask Ingemann Lambertsen]

On Tue, Jul 24, 2007 at 11:50:07AM -0700, Andrew Pinski wrote:
> On 7/24/07, Rask Ingemann Lambertsen <rask@sygehus.dk> wrote:

> >2007-07-24  Rask Ingemann Lambertsen  <rask@sygehus.dk>
> >
> >        * gcc.dg/torture/pr27743.c (bar): Use an integer of exactly 32 bits
> >        where required.
> >        * gcc.c-torture/execute/simd-1.c: Likewise.
> >        * gcc.c-torture/execute/pr23135.c: Likewise.
> >        * gcc.c-torture/execute/simd-4.c (__ev_convert_s64)(main): 
> >        Likewise.
> >        Use an integer of exactly 64 bits where required.
> 
> Why did you change the simd ones from using SImode?

   Simd-1.c and pr23135.c want a 16 byte vector with four elements. This
means four bytes per element. I don't know what the size of SImode is (or if
it even exists). For example, if you try this

Index: gcc.c-torture/execute/simd-1.c
===================================================================
--- gcc.c-torture/execute/simd-1.c      (revision 126653)
+++ gcc.c-torture/execute/simd-1.c      (working copy)
@@ -4,7 +4,7 @@
    regardless of if the target has SIMD instructions.
 */

-typedef int __attribute__((vector_size (16))) vecint;
+typedef int __attribute__((mode(SI))) __attribute__((vector_size (16))) vecint;
 typedef int __attribute__((mode(SI))) siint;

 vecint i = { 150, 100, 150, 200 };

on c4x-unknown-coff, you get

$ ./xgcc -B./ ~/simd-1.c -S -o /dev/null
/home/rask/simd-1.c:7: error: unable to emulate SI
/home/rask/simd-1.c:8: error: unable to emulate SI

and SImode would be 128-bits on that target. Simd-4.c makes an endianess test
and wants an 8 byte vector with two elements, each of which can hold at most
0xffffffff. All three testcases use a union for type conversion. Suggestions
are welcome.

-- 
Rask Ingemann Lambertsen

Re: [PATCH 5/5][testsuite] Use stdint.h when needing int of exact size

[Richard Guenther]

On 7/24/07, Rask Ingemann Lambertsen <rask@sygehus.dk> wrote:
> On Tue, Jul 24, 2007 at 11:50:07AM -0700, Andrew Pinski wrote:
> > On 7/24/07, Rask Ingemann Lambertsen <rask@sygehus.dk> wrote:
>
> > >2007-07-24  Rask Ingemann Lambertsen  <rask@sygehus.dk>
> > >
> > >        * gcc.dg/torture/pr27743.c (bar): Use an integer of exactly 32 bits
> > >        where required.
> > >        * gcc.c-torture/execute/simd-1.c: Likewise.
> > >        * gcc.c-torture/execute/pr23135.c: Likewise.
> > >        * gcc.c-torture/execute/simd-4.c (__ev_convert_s64)(main):
> > >        Likewise.
> > >        Use an integer of exactly 64 bits where required.
> >
> > Why did you change the simd ones from using SImode?
>
>    Simd-1.c and pr23135.c want a 16 byte vector with four elements. This
> means four bytes per element. I don't know what the size of SImode is (or if
> it even exists). For example, if you try this
>
> Index: gcc.c-torture/execute/simd-1.c
> ===================================================================
> --- gcc.c-torture/execute/simd-1.c      (revision 126653)
> +++ gcc.c-torture/execute/simd-1.c      (working copy)
> @@ -4,7 +4,7 @@
>     regardless of if the target has SIMD instructions.
>  */
>
> -typedef int __attribute__((vector_size (16))) vecint;
> +typedef int __attribute__((mode(SI))) __attribute__((vector_size (16))) vecint;
>  typedef int __attribute__((mode(SI))) siint;
>
>  vecint i = { 150, 100, 150, 200 };
>
> on c4x-unknown-coff, you get
>
> $ ./xgcc -B./ ~/simd-1.c -S -o /dev/null
> /home/rask/simd-1.c:7: error: unable to emulate SI
> /home/rask/simd-1.c:8: error: unable to emulate SI
>
> and SImode would be 128-bits on that target. Simd-4.c makes an endianess test
> and wants an 8 byte vector with two elements, each of which can hold at most
> 0xffffffff. All three testcases use a union for type conversion. Suggestions
> are welcome.

SImode is always 4 bytes and it is required to "exist".  So

typedef int __attribute__((mode(SI))) __attribute__((vector_size (16)))

cannot work.

Richard.

Re: [PATCH 5/5][testsuite] Use stdint.h when needing int of exact size

[Rask Ingemann Lambertsen]

On Tue, Jul 24, 2007 at 11:24:40PM +0200, Richard Guenther wrote:
> On 7/24/07, Rask Ingemann Lambertsen <rask@sygehus.dk> wrote:

> >on c4x-unknown-coff, you get
> >
> >$ ./xgcc -B./ ~/simd-1.c -S -o /dev/null
> >/home/rask/simd-1.c:7: error: unable to emulate SI
> >/home/rask/simd-1.c:8: error: unable to emulate SI
> >
> >and SImode would be 128-bits on that target. Simd-4.c makes an endianess 
> >test
> >and wants an 8 byte vector with two elements, each of which can hold at 
> >most
> >0xffffffff. All three testcases use a union for type conversion. 
> >Suggestions
> >are welcome.
> 
> SImode is always 4 bytes

   No. SImode is 4 * BITS_PER_UNIT and on the c4x, BITS_PER_UNIT is 32
so SImode is 128 bits on the c4x.

> and it is required to "exist".

   I do wonder how it has been disabled on the c4x.

> So
> 
> typedef int __attribute__((mode(SI))) __attribute__((vector_size (16)))
> 
> cannot work.

   It seems works fine on x86_64-unknown-linux-gnu to define them like this

typedef int __attribute__((mode(SI))) __attribute__((vector_size (16))) vecint;
typedef int __attribute__((mode(SI))) siint;

and the asm output contains the expected V4SI instructions, e.g.

        paddd   j(%rip), %xmm0  # 7     *addv4si3       [length = 8]
        movdqa  %xmm0, res(%rip)        # 10    *movv4si_internal/3 [length = 7]

-- 
Rask Ingemann Lambertsen

Re: [PATCH 5/5][testsuite] Use stdint.h when needing int of exact size

[Janis Johnson]

On Tue, 2007-07-24 at 19:24 +0200, Rask Ingemann Lambertsen wrote:
>    These testcases all rely on very specific integer sizes to pass. The
> vector tests assume the vectors have exactly four elements and simd-4.c
> additionally needs integers of exactly 32 bits and 64 bits. pr27743.c relies
> on sign extension of bit 31, so a signed 32-bit integer is required. This
> patch uses types from stdint.h to make sure that these requirements are
> met, also on targets where int gives you only 16 bits.
> 
>    Ok for trunk?
> 
> :ADDPATCH testsuite:
> 
> 2007-07-24  Rask Ingemann Lambertsen  <rask@sygehus.dk>
> 
> 	* gcc.dg/torture/pr27743.c (bar): Use an integer of exactly 32 bits
> 	where required.
> 	* gcc.c-torture/execute/simd-1.c: Likewise.
> 	* gcc.c-torture/execute/pr23135.c: Likewise.
> 	* gcc.c-torture/execute/simd-4.c (__ev_convert_s64)(main): Likewise.
> 	Use an integer of exactly 64 bits where required.

I agree with Andrew Pinski that you shouldn't change SImode in
these tests; it would be better to skip them for targets that
are not ILP32 or LP64.  It's also not right to change the return
value of main to something other than int, so I'd recommend also
skipping that one if not ILP32 or LP64.

Janis

Re: [PATCH 5/5][testsuite] Use stdint.h when needing int of exact size

[Rask Ingemann Lambertsen]

On Tue, Jul 24, 2007 at 02:25:43PM -0700, Janis Johnson wrote:
> On Tue, 2007-07-24 at 19:24 +0200, Rask Ingemann Lambertsen wrote:
> > 
> > 	* gcc.dg/torture/pr27743.c (bar): Use an integer of exactly 32 bits
> > 	where required.
> > 	* gcc.c-torture/execute/simd-1.c: Likewise.
> > 	* gcc.c-torture/execute/pr23135.c: Likewise.
> > 	* gcc.c-torture/execute/simd-4.c (__ev_convert_s64)(main): Likewise.
> > 	Use an integer of exactly 64 bits where required.
[snip]

> It's also not right to change the return
> value of main to something other than int, so I'd recommend also
> skipping that one if not ILP32 or LP64.

   Where do I change the return value of main?

-- 
Rask Ingemann Lambertsen

Re: [PATCH 5/5][testsuite] Use stdint.h when needing int of exact size

[Janis Johnson]

On Wed, 2007-07-25 at 15:26 +0200, Rask Ingemann Lambertsen wrote:
> On Tue, Jul 24, 2007 at 02:25:43PM -0700, Janis Johnson wrote:
> > On Tue, 2007-07-24 at 19:24 +0200, Rask Ingemann Lambertsen wrote:
> > > 
> > > 	* gcc.dg/torture/pr27743.c (bar): Use an integer of exactly 32 bits
> > > 	where required.
> > > 	* gcc.c-torture/execute/simd-1.c: Likewise.
> > > 	* gcc.c-torture/execute/pr23135.c: Likewise.
> > > 	* gcc.c-torture/execute/simd-4.c (__ev_convert_s64)(main): Likewise.
> > > 	Use an integer of exactly 64 bits where required.
> [snip]
> 
> > It's also not right to change the return
> > value of main to something other than int, so I'd recommend also
> > skipping that one if not ILP32 or LP64.
> 
>    Where do I change the return value of main?

Um, apparently in my imagination; sorry about that.

Janis

Re: [PATCH 5/5][testsuite] Use stdint.h when needing int of exact size

[Rask Ingemann Lambertsen]

On Tue, Jul 24, 2007 at 02:25:43PM -0700, Janis Johnson wrote:
> On Tue, 2007-07-24 at 19:24 +0200, Rask Ingemann Lambertsen wrote:
> > 
> > 2007-07-24  Rask Ingemann Lambertsen  <rask@sygehus.dk>
> > 
> > 	* gcc.dg/torture/pr27743.c (bar): Use an integer of exactly 32 bits
> > 	where required.
> > 	* gcc.c-torture/execute/simd-1.c: Likewise.
> > 	* gcc.c-torture/execute/pr23135.c: Likewise.
> > 	* gcc.c-torture/execute/simd-4.c (__ev_convert_s64)(main): Likewise.
> > 	Use an integer of exactly 64 bits where required.
> 
> I agree with Andrew Pinski that you shouldn't change SImode in
> these tests; it would be better to skip them for targets that
> are not ILP32 or LP64.

   How about this patch which instead forces the vector elements to be
SImode ones? The asm output is unchanged on x86_64-unknown-linux-gnu and I
have verified that pr23135.c still triggers the reload bug in PR 23135 on
trunk revision 102771.

2007-08-28  Rask Ingemann Lambertsen  <rask@sygehus.dk>

	* gcc.c-torture/execute/simd-1.c: Use SImode vector elements.
	* gcc.c-torture/execute/pr23135.c: Likewise.

Index: gcc.c-torture/execute/simd-1.c
===================================================================
--- gcc.c-torture/execute/simd-1.c	(revision 126653)
+++ gcc.c-torture/execute/simd-1.c	(working copy)
@@ -4,7 +4,7 @@
    regardless of if the target has SIMD instructions.
 */
 
-typedef int __attribute__((vector_size (16))) vecint;
+typedef int __attribute__((mode(SI))) __attribute__((vector_size (16))) vecint;
 typedef int __attribute__((mode(SI))) siint;
 
 vecint i = { 150, 100, 150, 200 };
Index: gcc.c-torture/execute/pr23135.c
===================================================================
--- gcc.c-torture/execute/pr23135.c	(revision 126653)
+++ gcc.c-torture/execute/pr23135.c	(working copy)
@@ -7,7 +7,7 @@
 
 typedef struct { char c[STACK_SIZE/2]; } big_t;
 
-typedef int __attribute__((vector_size (8))) vecint;
+typedef int __attribute__((mode(SI))) __attribute__((vector_size (8))) vecint;
 typedef int __attribute__((mode(SI))) siint;
 
 vecint i = { 150, 100 };


-- 
Rask Ingemann Lambertsen

Re: [PATCH 5/5][testsuite] Use stdint.h when needing int of exact size

[Janis Johnson]

On Tue, 2007-08-28 at 14:53 +0200, Rask Ingemann Lambertsen wrote:
>    How about this patch which instead forces the vector elements to be
> SImode ones? The asm output is unchanged on x86_64-unknown-linux-gnu and I
> have verified that pr23135.c still triggers the reload bug in PR 23135 on
> trunk revision 102771.

This is OK.

Janis

Re: [PATCH 5/5][testsuite] Use stdint.h when needing int of exact size

[Rask Ingemann Lambertsen]

On Tue, Jul 24, 2007 at 07:24:53PM +0200, Rask Ingemann Lambertsen wrote:

> pr27743.c relies
> on sign extension of bit 31, so a signed 32-bit integer is required. This
> patch uses types from stdint.h to make sure that these requirements are
> met, also on targets where int gives you only 16 bits.

> Index: gcc.dg/torture/pr27743.c
> ===================================================================
> --- gcc.dg/torture/pr27743.c	(revision 126653)
> +++ gcc.dg/torture/pr27743.c	(working copy)
> @@ -1,10 +1,11 @@
> -/* { dg-do run } */
> +/* { dg-do run { target { stdint_types } } } */
>  
> +#include <stdint.h>
>  extern void abort(void);
>  
> -int bar(int a)
> +int32_t bar (int32_t a)
>  {
> -  return ((unsigned) ((a) >> 2)) >> 15;
> +  return ((uint32_t) ((a) >> 2)) >> 15;
>  }
>  
>  int main()

   Are there any comments on this part? I'll use this ChangeLog entry:

2007-07-26  Rask Ingemann Lambertsen  <rask@sygehus.dk>

	* gcc.dg/torture/pr27743.c (bar): Use an integer of exactly 32 bits
	because the test relies on bit 31 to be the sign bit.

-- 
Rask Ingemann Lambertsen

Re: [PATCH 5/5][testsuite] Use stdint.h when needing int of exact size

[Janis Johnson]

On Thu, 2007-07-26 at 11:25 +0200, Rask Ingemann Lambertsen wrote:
> On Tue, Jul 24, 2007 at 07:24:53PM +0200, Rask Ingemann Lambertsen wrote:
> 
> > pr27743.c relies
> > on sign extension of bit 31, so a signed 32-bit integer is required. This
> > patch uses types from stdint.h to make sure that these requirements are
> > met, also on targets where int gives you only 16 bits.
> 
> > Index: gcc.dg/torture/pr27743.c
> > ===================================================================
> > --- gcc.dg/torture/pr27743.c	(revision 126653)
> > +++ gcc.dg/torture/pr27743.c	(working copy)
> > @@ -1,10 +1,11 @@
> > -/* { dg-do run } */
> > +/* { dg-do run { target { stdint_types } } } */
> >  
> > +#include <stdint.h>
> >  extern void abort(void);
> >  
> > -int bar(int a)
> > +int32_t bar (int32_t a)
> >  {
> > -  return ((unsigned) ((a) >> 2)) >> 15;
> > +  return ((uint32_t) ((a) >> 2)) >> 15;
> >  }
> >  
> >  int main()
> 
>    Are there any comments on this part? I'll use this ChangeLog entry:
> 
> 2007-07-26  Rask Ingemann Lambertsen  <rask@sygehus.dk>
> 
> 	* gcc.dg/torture/pr27743.c (bar): Use an integer of exactly 32 bits
> 	because the test relies on bit 31 to be the sign bit.

This is OK.

Janis

Re: [PATCH 5/5][testsuite] Use stdint.h when needing int of exact size

[Rask Ingemann Lambertsen]

On Tue, Jul 24, 2007 at 07:24:53PM +0200, Rask Ingemann Lambertsen wrote:
> 
> Index: gcc.c-torture/execute/simd-4.c
> ===================================================================
> --- gcc.c-torture/execute/simd-4.c	(revision 126653)
> +++ gcc.c-torture/execute/simd-4.c	(working copy)
> @@ -1,17 +1,18 @@
> -typedef int __attribute__((vector_size(8))) v2si;
> -long long s64;
> +#include <stdint.h>
> +typedef int32_t __attribute__((vector_size(8))) v2si;
> +int64_t s64;
>  
> -static inline long long
> +static inline int64_t
>  __ev_convert_s64 (v2si a)
>  {
> -  return (long long) a;
> +  return (int64_t) a;
>  }
>  
>  int main()
>  {
> -  union { long long ll; int i[2]; } endianness_test;
> +  union { int64_t ll; int32_t i[2]; } endianness_test;
>    endianness_test.ll = 1;
> -  int little_endian = endianness_test.i[0];
> +  int32_t little_endian = endianness_test.i[0];
>    s64 = __ev_convert_s64 ((v2si){1,0xffffffff});
>    if (s64 != (little_endian ? 0xffffffff00000001LL : 0x1ffffffffLL))
>      abort ();

   I don't think this part was commented on yet. Is it ok?

2007-08-05  Rask Ingemann Lambertsen  <rask@sygehus.dk>

	* gcc.c-torture/execute/simd-4.c (__ev_convert_s64)(main): Use
	  int32_t for 32-bit integer. Use int64_t for 64-bit integer.

-- 
Rask Ingemann Lambertsen

Re: [PATCH 5/5][testsuite] Use stdint.h when needing int of exact size

[Janis Johnson]

On Sun, 2007-08-05 at 13:40 +0200, Rask Ingemann Lambertsen wrote:
> On Tue, Jul 24, 2007 at 07:24:53PM +0200, Rask Ingemann Lambertsen wrote:
> > 
> > Index: gcc.c-torture/execute/simd-4.c
> > ===================================================================
> > --- gcc.c-torture/execute/simd-4.c	(revision 126653)
> > +++ gcc.c-torture/execute/simd-4.c	(working copy)
> > @@ -1,17 +1,18 @@
> > -typedef int __attribute__((vector_size(8))) v2si;
> > -long long s64;
> > +#include <stdint.h>
> > +typedef int32_t __attribute__((vector_size(8))) v2si;
> > +int64_t s64;
> >  
> > -static inline long long
> > +static inline int64_t
> >  __ev_convert_s64 (v2si a)
> >  {
> > -  return (long long) a;
> > +  return (int64_t) a;
> >  }
> >  
> >  int main()
> >  {
> > -  union { long long ll; int i[2]; } endianness_test;
> > +  union { int64_t ll; int32_t i[2]; } endianness_test;
> >    endianness_test.ll = 1;
> > -  int little_endian = endianness_test.i[0];
> > +  int32_t little_endian = endianness_test.i[0];
> >    s64 = __ev_convert_s64 ((v2si){1,0xffffffff});
> >    if (s64 != (little_endian ? 0xffffffff00000001LL : 0x1ffffffffLL))
> >      abort ();
> 
>    I don't think this part was commented on yet. Is it ok?
> 
> 2007-08-05  Rask Ingemann Lambertsen  <rask@sygehus.dk>
> 
> 	* gcc.c-torture/execute/simd-4.c (__ev_convert_s64)(main): Use
> 	  int32_t for 32-bit integer. Use int64_t for 64-bit integer.

This is OK.

Janis

Re: [PATCH 5/5][testsuite] Use stdint.h when needing int of exact size

[Daniel Jacobowitz]

On Mon, Aug 06, 2007 at 12:32:23PM -0700, Janis Johnson wrote:
> On Sun, 2007-08-05 at 13:40 +0200, Rask Ingemann Lambertsen wrote:
> > On Tue, Jul 24, 2007 at 07:24:53PM +0200, Rask Ingemann Lambertsen wrote:
> > > +#include <stdint.h>
> > > +typedef int32_t __attribute__((vector_size(8))) v2si;
> > > +int64_t s64;

Why can we assume in the testsuite that <stdint.h> is available?  I'm
almost positive there are other supported targets without it; the one
I can name off the top of my head is VxWorks.

-- 
Daniel Jacobowitz
CodeSourcery

RE: [PATCH 5/5][testsuite] Use stdint.h when needing int of exact size

[Eric Weddington]

> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@false.org]
> Sent: Tuesday, August 07, 2007 11:46 AM
> To: Janis Johnson
> Cc: Rask Ingemann Lambertsen; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH 5/5][testsuite] Use stdint.h when needing
> int of exact size
>
> On Mon, Aug 06, 2007 at 12:32:23PM -0700, Janis Johnson wrote:
> > On Sun, 2007-08-05 at 13:40 +0200, Rask Ingemann Lambertsen wrote:
> > > On Tue, Jul 24, 2007 at 07:24:53PM +0200, Rask Ingemann
> Lambertsen wrote:
> > > > +#include <stdint.h>
> > > > +typedef int32_t __attribute__((vector_size(8))) v2si;
> > > > +int64_t s64;
>
> Why can we assume in the testsuite that <stdint.h> is available?  I'm
> almost positive there are other supported targets without it; the one
> I can name off the top of my head is VxWorks.

Do you have an alternative in mind?
A number of tests will have to be changed in the future to use something
like <stdint.h> to have them work for the AVR (16-bit int, 32-bit long). And
avr-libc has <stdint.h> available.

Eric Weddington

Re: [PATCH 5/5][testsuite] Use stdint.h when needing int of exact size

['Daniel Jacobowitz']

On Tue, Aug 07, 2007 at 01:33:49PM -0600, Eric Weddington wrote:
> Do you have an alternative in mind?
> A number of tests will have to be changed in the future to use something
> like <stdint.h> to have them work for the AVR (16-bit int, 32-bit long). And
> avr-libc has <stdint.h> available.

No, but I assume we'll have to do one of:

 - make the test harness start synthesizing an appropriate header
 - make the compiler define some appropriate macros
 - just make gcc provide <stdint.h>

Autoconf's manual suggests another platform without <stdint.h> is
Solaris 7.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [PATCH 5/5][testsuite] Use stdint.h when needing int of exact size

[Janis Johnson]

On Tue, 2007-08-07 at 15:41 -0400, 'Daniel Jacobowitz' wrote:
> On Tue, Aug 07, 2007 at 01:33:49PM -0600, Eric Weddington wrote:
> > Do you have an alternative in mind?
> > A number of tests will have to be changed in the future to use something
> > like <stdint.h> to have them work for the AVR (16-bit int, 32-bit long). And
> > avr-libc has <stdint.h> available.
> 
> No, but I assume we'll have to do one of:
> 
>  - make the test harness start synthesizing an appropriate header
>  - make the compiler define some appropriate macros
>  - just make gcc provide <stdint.h>
> 
> Autoconf's manual suggests another platform without <stdint.h> is
> Solaris 7.

It's also not available on HPPA HP-UX.  Until there's a long-term
solution, tests that need to include <stdint.h> should be skipped
if the effective target stdint_types is not true, as in

  { dg-require-effective-target stdint_types }

Janis

Re: [PATCH 5/5][testsuite] Use stdint.h when needing int of exact size

[Ian Lance Taylor]

Eric Weddington <eweddington@cso.atmel.com> writes:

> > Why can we assume in the testsuite that <stdint.h> is available?  I'm
> > almost positive there are other supported targets without it; the one
> > I can name off the top of my head is VxWorks.
> 
> Do you have an alternative in mind?

One alternative is __attribute__ ((mode ())).  Although that shifts
the problem to machines for which BITS_PER_UNIT != 8.

Ian

Re: [PATCH 5/5][testsuite] Use stdint.h when needing int of exact size

[Rask Ingemann Lambertsen]

On Tue, Aug 07, 2007 at 01:45:48PM -0400, Daniel Jacobowitz wrote:
> 
> Why can we assume in the testsuite that <stdint.h> is available?  I'm
> almost positive there are other supported targets without it; the one
> I can name off the top of my head is VxWorks.

   We can't. I had gotten the idea that GCC provides stdint.h, but that's
stddef.h. I'll submit a patch to check for availability of stdint.h. I'll
also see if the check is missing in some of the other recently modified test
cases.

  Why doesn't GCC provide stdint.h, btw? The one from newlib at least seems
to rely only on stuff provided by GCC.

-- 
Rask Ingemann Lambertsen

Re: [PATCH 5/5][testsuite] Use stdint.h when needing int of exact size

[Daniel Jacobowitz]

On Wed, Aug 08, 2007 at 01:46:07AM +0200, Rask Ingemann Lambertsen wrote:
>   Why doesn't GCC provide stdint.h, btw? The one from newlib at least seems
> to rely only on stuff provided by GCC.

I don't know, but I think there was a good reason involving things the
library has to know also.  Joseph, do you know?

-- 
Daniel Jacobowitz
CodeSourcery

Re: [PATCH 5/5][testsuite] Use stdint.h when needing int of exact size

[Daniel Jacobowitz]

On Tue, Aug 07, 2007 at 10:14:09PM -0400, Daniel Jacobowitz wrote:
> I don't know, but I think there was a good reason involving things the
> library has to know also.  Joseph, do you know?

Look, ma, I can use the internet too!

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448

I think at this point it's just a matter of doing the work.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [PATCH 5/5][testsuite] Use stdint.h when needing int of exact size

[Joseph S. Myers]

On Tue, 7 Aug 2007, Daniel Jacobowitz wrote:

> On Tue, Aug 07, 2007 at 10:14:09PM -0400, Daniel Jacobowitz wrote:
> > I don't know, but I think there was a good reason involving things the
> > library has to know also.  Joseph, do you know?
> 
> Look, ma, I can use the internet too!
> 
>   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
> 
> I think at this point it's just a matter of doing the work.

In particular, of collating the rules used by all the supported systems 
with their own <stdint.h> or <inttypes.h>, or which define the same type 
names in other headers, so as to be consistent with them on systems which 
already have these types.  (glibc and newlib use different logic to 
determine the types, for example.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH 5/5][testsuite] Use stdint.h when needing int of exact size

[H. Peter Anvin]

Joseph S. Myers wrote:
> 
> In particular, of collating the rules used by all the supported systems 
> with their own <stdint.h> or <inttypes.h>, or which define the same type 
> names in other headers, so as to be consistent with them on systems which 
> already have these types.  (glibc and newlib use different logic to 
> determine the types, for example.)
> 

I don't think there are any systems in the field which has <stdint.h>
but not <inttypes.h>.  <stdint.h> is there mostly because it imports a
smaller set of things, which can be important in library construction
and/or library-compiler separation.

	-hpa

Re: [PATCH 5/5][testsuite] Use stdint.h when needing int of exact size

[Rask Ingemann Lambertsen]

On Tue, Aug 07, 2007 at 01:45:48PM -0400, Daniel Jacobowitz wrote:
> On Mon, Aug 06, 2007 at 12:32:23PM -0700, Janis Johnson wrote:
> > On Sun, 2007-08-05 at 13:40 +0200, Rask Ingemann Lambertsen wrote:
> > > On Tue, Jul 24, 2007 at 07:24:53PM +0200, Rask Ingemann Lambertsen wrote:
> > > > +#include <stdint.h>
> > > > +typedef int32_t __attribute__((vector_size(8))) v2si;
> > > > +int64_t s64;
> 
> Why can we assume in the testsuite that <stdint.h> is available?  I'm
> almost positive there are other supported targets without it; the one
> I can name off the top of my head is VxWorks.

   This patch disables the test when stdint.h isn't available. I've tested
that it still runs on x86_64-unknown-linux-gnu, but I don't have any targets
without stdint.h to test on.

   I also checked the other ones I've fixed for 16-bit targets, but this was
the only one where the check for stdint.h was missing.

2007-08-22  Rask Ingemann Lambertsen  <rask@sygehus.dk>

	* gcc.c-torture/execute/simd-4.x: Only run when stdint.h types are
	  available.

Index: gcc.c-torture/execute/simd-4.x
===================================================================
--- gcc.c-torture/execute/simd-4.x	(revision 0)
+++ gcc.c-torture/execute/simd-4.x	(revision 0)
@@ -0,0 +1,7 @@
+load_lib target-supports.exp
+
+if { [check_effective_target_stdint_types] } {
+	return 0
+}
+
+return 1;

-- 
Rask Ingemann Lambertsen

Re: [PATCH 5/5][testsuite] Use stdint.h when needing int of exact size

[Janis Johnson]

On Wed, 2007-08-22 at 20:50 +0200, Rask Ingemann Lambertsen wrote:
> 2007-08-22  Rask Ingemann Lambertsen  <rask@sygehus.dk>
> 
> 	* gcc.c-torture/execute/simd-4.x: Only run when stdint.h types are
> 	  available.

OK.

Janis

[PATCH 4/5][testsuite] Fix overflows with 16-bit int

[Rask Ingemann Lambertsen]

   With a 16-bit int, the first of these two tests cause an overflow during
addition, resulting in an execution failure. By casting to "unsigned long",
the overflow is avoided.

   The second testcase will overflow already when setting up the fib array:

    fib[i] = (fib[i-1] + fib[i - 2]) & 0xffff;

Clamping to 0xffff doesn't help when the maximum fib[i] can hold is 0x7ffff,
so the execution test fails. It is fixed by using a longer, signed integer.

   Ok for trunk?

:ADDPATCH testsuite:

2007-07-24  Rask Ingemann Lambertsen  <rask@sygehus.dk>

	* gcc.dg/tree-ssa/predcom-1.c (count_averages): Avoid overflow
	  during addition if an int is only 16 bits wide.
	* gcc.dg/tree-ssa/predcom-2.c (fib): Avoid overflow of 16-bit int.

Index: gcc.dg/tree-ssa/predcom-1.c
===================================================================
--- gcc.dg/tree-ssa/predcom-1.c	(revision 126653)
+++ gcc.dg/tree-ssa/predcom-1.c	(working copy)
@@ -23,7 +23,7 @@ void count_averages(int n)
   int i;
 
   for (i = 1; i < n; i++)
-    avg[i] = ((fib[i - 1] + fib[i] + fib[i + 1]) / 3) & 0xffff;
+    avg[i] = (((unsigned long) fib[i - 1] + fib[i] + fib[i + 1]) / 3) & 0xffff;
 }
 
 int main(void)
Index: gcc.dg/tree-ssa/predcom-2.c
===================================================================
--- gcc.dg/tree-ssa/predcom-2.c	(revision 126653)
+++ gcc.dg/tree-ssa/predcom-2.c	(working copy)
@@ -4,7 +4,7 @@
 
 void abort (void);
 
-int fib[1000];
+long int fib[1000];
 
 void count_fib(void)
 {

-- 
Rask Ingemann Lambertsen

Re: [PATCH 4/5][testsuite] Fix overflows with 16-bit int

[Janis Johnson]

On Tue, 2007-07-24 at 19:13 +0200, Rask Ingemann Lambertsen wrote:
>    With a 16-bit int, the first of these two tests cause an overflow during
> addition, resulting in an execution failure. By casting to "unsigned long",
> the overflow is avoided.
> 
>    The second testcase will overflow already when setting up the fib array:
> 
>     fib[i] = (fib[i-1] + fib[i - 2]) & 0xffff;
> 
> Clamping to 0xffff doesn't help when the maximum fib[i] can hold is 0x7ffff,
> so the execution test fails. It is fixed by using a longer, signed integer.
> 
>    Ok for trunk?
> 
> :ADDPATCH testsuite:
> 
> 2007-07-24  Rask Ingemann Lambertsen  <rask@sygehus.dk>
> 
> 	* gcc.dg/tree-ssa/predcom-1.c (count_averages): Avoid overflow
> 	  during addition if an int is only 16 bits wide.
> 	* gcc.dg/tree-ssa/predcom-2.c (fib): Avoid overflow of 16-bit int.

:REVIEWMAIL:

OK.

Janis

[PATCH 2/5][testsuite] Match bit-fields width to that of an int

[Rask Ingemann Lambertsen]

   This patch fixes a testcase which fails with "excess errors" because the
bit-field is too wide for a 16-bit int. To trigger bug 30313, the bit-field
must be exactly as wide as an int. I have checked that it still fails with
GCC 4.1.2 for i686-pc-linux-gnu. Ok for trunk?

:ADDPATCH testsuite:

2007-07-24  Rask Ingemann Lambertsen  <rask@sygehus.dk>

	* gcc.dg/torture/pr30313.c (struct S): Make sure the bit-field is
	  exactly as wide as an int.

Index: gcc.dg/torture/pr30313.c
===================================================================
--- gcc.dg/torture/pr30313.c	(revision 126653)
+++ gcc.dg/torture/pr30313.c	(working copy)
@@ -4,7 +4,15 @@
 
 struct S
 {
+#if __INT_MAX__ == 32767
+  signed int i: 16;
+#elif __INT_MAX__ == 2147483647
   signed int i: 32;
+#elif __INT_MAX__ == 9223372036854775807
+  signed int i: 64;
+#else
+#error Please add support for your target here
+#endif
 };
 
 int main()

-- 
Rask Ingemann Lambertsen

Re: [PATCH 2/5][testsuite] Match bit-fields width to that of an int

[Janis Johnson]

On Tue, 2007-07-24 at 18:51 +0200, Rask Ingemann Lambertsen wrote:
>    This patch fixes a testcase which fails with "excess errors" because the
> bit-field is too wide for a 16-bit int. To trigger bug 30313, the bit-field
> must be exactly as wide as an int. I have checked that it still fails with
> GCC 4.1.2 for i686-pc-linux-gnu. Ok for trunk?
> 
> :ADDPATCH testsuite:
> 
> 2007-07-24  Rask Ingemann Lambertsen  <rask@sygehus.dk>
> 
> 	* gcc.dg/torture/pr30313.c (struct S): Make sure the bit-field is
> 	  exactly as wide as an int.

:REVIEWMAIL:

OK.

Janis

[PATCH 1/5][testsuite] Use INT_MAX instead of 0x7fffffff

[Rask Ingemann Lambertsen]

   This patch fixes three testcases which assume INT_MAX is 0x7fffffff. Ok
for trunk?

:ADDPATCH testsuite:

2007-07-24  Rask Ingemann Lambertsen  <rask@sygehus.dk>

	* gcc.c-torture/execute/pr28651.c (main): Use INT_MAX instead of
	  assuming it is 0x7fffffff.
	* gcc.dg/tree-ssa/vrp29.c (decCompare)(main): Likewise.
	* gcc.dg/Wconversion-integer-no-sign.c (h): Likewise.

Index: gcc.c-torture/execute/pr28651.c
===================================================================
--- gcc.c-torture/execute/pr28651.c	(revision 126653)
+++ gcc.c-torture/execute/pr28651.c	(working copy)
@@ -1,3 +1,5 @@
+#include <limits.h>
+
 extern void abort (void);
 int __attribute__((noinline))
 foo (unsigned int u)
@@ -8,7 +10,7 @@ foo (unsigned int u)
 int
 main (int argc, char *argv[])
 {
-  unsigned int u = 0x7fffffff;
+  unsigned int u = INT_MAX;
 
   if (foo (u) == 0)
     abort();
Index: gcc.dg/tree-ssa/vrp29.c
===================================================================
--- gcc.dg/tree-ssa/vrp29.c	(revision 126653)
+++ gcc.dg/tree-ssa/vrp29.c	(working copy)
@@ -1,20 +1,21 @@
 /* { dg-do run } */
 /* { dg-options "-O2" } */
+#include <limits.h>
 
 extern void abort(void);
 
 void decCompareOp (int result)
 {
-  if (result != (int)0x80000000)
+  if (result != (int) (INT_MAX + 1U))
     {
       result = -result;
-      if (result != (int)0x80000001)
+      if (result != (int) (INT_MAX + 2U))
         abort ();
     }
 }
 
 int main()
 {
-  decCompareOp (0x7fffffff);
+  decCompareOp (INT_MAX);
   return 0;
 }
Index: gcc.dg/Wconversion-integer-no-sign.c
===================================================================
--- gcc.dg/Wconversion-integer-no-sign.c	(revision 126653)
+++ gcc.dg/Wconversion-integer-no-sign.c	(working copy)
@@ -60,8 +60,8 @@ void h (int x)
   uc = '\xa0'; /* Warned by -Wsign-conversion.  */
   fui ('\xa0'); /* Warned by -Wsign-conversion.  */
   ui = '\xa0';  /* Warned by -Wsign-conversion.  */
-  fsi (0x80000000); /* Warned by -Wsign-conversion.  */
-  si = 0x80000000;  /* Warned by -Wsign-conversion.  */
+  fsi ((unsigned) INT_MAX + 1U); /* Warned by -Wsign-conversion.  */
+  si = (unsigned) INT_MAX + 1U;  /* Warned by -Wsign-conversion.  */
 
 
   fsi (UINT_MAX - 1);  /* Warned by -Wsign-conversion.  */

-- 
Rask Ingemann Lambertsen

Re: [PATCH 1/5][testsuite] Use INT_MAX instead of 0x7fffffff

[Janis Johnson]

On Tue, 2007-07-24 at 18:07 +0200, Rask Ingemann Lambertsen wrote:
>    This patch fixes three testcases which assume INT_MAX is 0x7fffffff. Ok
> for trunk?
> 
> :ADDPATCH testsuite:
> 
> 2007-07-24  Rask Ingemann Lambertsen  <rask@sygehus.dk>
> 
> 	* gcc.c-torture/execute/pr28651.c (main): Use INT_MAX instead of
> 	  assuming it is 0x7fffffff.
> 	* gcc.dg/tree-ssa/vrp29.c (decCompare)(main): Likewise.
> 	* gcc.dg/Wconversion-integer-no-sign.c (h): Likewise.

:REVIEWMAIL:

The first and third are OK but I'm not sure about the second.
Richard Guenther, do the changes to the additions in vrp29.c
require additional casts?

> Index: gcc.dg/tree-ssa/vrp29.c
> ===================================================================
> --- gcc.dg/tree-ssa/vrp29.c	(revision 126653)
> +++ gcc.dg/tree-ssa/vrp29.c	(working copy)
> @@ -1,20 +1,21 @@
>  /* { dg-do run } */
>  /* { dg-options "-O2" } */
> +#include <limits.h>
> 
>  extern void abort(void);
> 
>  void decCompareOp (int result)
>  {
> -  if (result != (int)0x80000000)
> +  if (result != (int) (INT_MAX + 1U))
>      {
>        result = -result;
> -      if (result != (int)0x80000001)
> +      if (result != (int) (INT_MAX + 2U))
>          abort ();
>      }
>  }
> 
>  int main()
>  {
> -  decCompareOp (0x7fffffff);
> +  decCompareOp (INT_MAX);
>    return 0;
>  }

Re: [PATCH 1/5][testsuite] Use INT_MAX instead of 0x7fffffff

[Richard Guenther]

On Tue, 24 Jul 2007, Janis Johnson wrote:

> On Tue, 2007-07-24 at 18:07 +0200, Rask Ingemann Lambertsen wrote:
> >    This patch fixes three testcases which assume INT_MAX is 0x7fffffff. Ok
> > for trunk?
> > 
> > :ADDPATCH testsuite:
> > 
> > 2007-07-24  Rask Ingemann Lambertsen  <rask@sygehus.dk>
> > 
> > 	* gcc.c-torture/execute/pr28651.c (main): Use INT_MAX instead of
> > 	  assuming it is 0x7fffffff.
> > 	* gcc.dg/tree-ssa/vrp29.c (decCompare)(main): Likewise.
> > 	* gcc.dg/Wconversion-integer-no-sign.c (h): Likewise.
> 
> :REVIEWMAIL:
> 
> The first and third are OK but I'm not sure about the second.
> Richard Guenther, do the changes to the additions in vrp29.c
> require additional casts?

I think they are fine.  INT_MAX + 1U is promoted to unsigned arithmetic.
Rask, did you verify we still constant fold the constant operations?
(it would be a bug if not, of course).

Richard.

> > Index: gcc.dg/tree-ssa/vrp29.c
> > ===================================================================
> > --- gcc.dg/tree-ssa/vrp29.c	(revision 126653)
> > +++ gcc.dg/tree-ssa/vrp29.c	(working copy)
> > @@ -1,20 +1,21 @@
> >  /* { dg-do run } */
> >  /* { dg-options "-O2" } */
> > +#include <limits.h>
> > 
> >  extern void abort(void);
> > 
> >  void decCompareOp (int result)
> >  {
> > -  if (result != (int)0x80000000)
> > +  if (result != (int) (INT_MAX + 1U))
> >      {
> >        result = -result;
> > -      if (result != (int)0x80000001)
> > +      if (result != (int) (INT_MAX + 2U))
> >          abort ();
> >      }
> >  }
> > 
> >  int main()
> >  {
> > -  decCompareOp (0x7fffffff);
> > +  decCompareOp (INT_MAX);
> >    return 0;
> >  }
> 
> 
> 

-- 
Richard Guenther <rguenther@suse.de>
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex

Re: [PATCH 1/5][testsuite] Use INT_MAX instead of 0x7fffffff

[Rask Ingemann Lambertsen]

On Tue, Jul 24, 2007 at 11:27:22PM +0200, Richard Guenther wrote:
> On Tue, 24 Jul 2007, Janis Johnson wrote:
> 
> > The first and third are OK but I'm not sure about the second.
> > Richard Guenther, do the changes to the additions in vrp29.c
> > require additional casts?
> 
> I think they are fine.  INT_MAX + 1U is promoted to unsigned arithmetic.
> Rask, did you verify we still constant fold the constant operations?
> (it would be a bug if not, of course).

   I'm not sure exactly which dump file would show that, but I diffed the
output of -fdump-tree-all with and without the patch, and the only change
was in the line numbers.

-- 
Rask Ingemann Lambertsen

[PATCH 3/5][testsuite] Disable tests if pointer and long int are not both 32-bits or 64-bits

[Rask Ingemann Lambertsen]

   These two tests need "long int" and pointers to have the same size and be
at least 32 bits wide. I couldn't find any obviously good way of fixing
that, so this patch simply disables these two tests on all other targets
than ilp32 and lp64 ones. Ok for trunk?

:ADDPATCH testsuite:

2007-07-24  Rask Ingemann Lambertsen  <rask@sygehus.dk>

	* gcc.dg/torture/pr29584.c: Only run test if pointers have the same
	  size as "long int" and are 32 or 64 bits wide.
	* gcc.dg/torture/pr28814.c: Likewise.

Index: gcc.dg/torture/pr29584.c
===================================================================
--- gcc.dg/torture/pr29584.c	(revision 126653)
+++ gcc.dg/torture/pr29584.c	(working copy)
@@ -1,5 +1,5 @@
 /* PR middle-end/29584 */
-/* { dg-do compile } */
+/* { dg-do compile { target { ilp32 || lp64 } } } */
 
 extern void *foo1 (void);
 extern void foo2 (void);
Index: gcc.dg/torture/pr28814.c
===================================================================
--- gcc.dg/torture/pr28814.c	(revision 126653)
+++ gcc.dg/torture/pr28814.c	(working copy)
@@ -1,4 +1,4 @@
-/* { dg-do compile } */
+/* { dg-do compile { target { ilp32 || lp64 } } } */
 
 struct w49
 {

-- 
Rask Ingemann Lambertsen

Re: [PATCH 3/5][testsuite] Disable tests if pointer and long int are not both 32-bits or 64-bits

[Janis Johnson]

On Tue, 2007-07-24 at 18:57 +0200, Rask Ingemann Lambertsen wrote:
>    These two tests need "long int" and pointers to have the same size and be
> at least 32 bits wide. I couldn't find any obviously good way of fixing
> that, so this patch simply disables these two tests on all other targets
> than ilp32 and lp64 ones. Ok for trunk?
> 
> :ADDPATCH testsuite:
> 
> 2007-07-24  Rask Ingemann Lambertsen  <rask@sygehus.dk>
> 
> 	* gcc.dg/torture/pr29584.c: Only run test if pointers have the same
> 	  size as "long int" and are 32 or 64 bits wide.
> 	* gcc.dg/torture/pr28814.c: Likewise.

:REVIEWMAIL:

OK.

Janis