diff mbox series

testsuite: Adjust fam-in-union-alone-in-struct-2.c to support BE [PR116148]

Message ID fdd0e26a-cfd9-2928-ebc9-fe0ee46e79af@linux.ibm.com
State New
Headers show
Series testsuite: Adjust fam-in-union-alone-in-struct-2.c to support BE [PR116148] | expand

Commit Message

Kewen.Lin July 31, 2024, 9:22 a.m. UTC 
Hi,

As Andrew pointed out in PR116148, fam-in-union-alone-in-struct-2.c
was designed for little-endian, the recent commit r15-2403 made it
be tested with running on BE and PR116148 got exposed.

This patch is to adjust the expected data for members in with_fam_2_v
and with_fam_3_v by considering endianness, also update with_fam_3_v.b[1]
from 0x5f6f7f7f to 0x5f6f7f8f to avoid two "7f"s.

Tested on powerpc64-linux-gnu P8/P9 and powerpc64le-linux-gnu P9/P10.

Is it ok for trunk?

BR,
Kewen
-----
	PR testsuite/116148

gcc/testsuite/ChangeLog:

	* c-c++-common/fam-in-union-alone-in-struct-2.c: Define macros
	WITH_FAM_2_V_B[03] and WITH_FAM_3_V_A[07] as endianness, update the
	checking with these macros and initialize with_fam_3_v.b[1] with
	0x5f6f7f8f instead of 0x5f6f7f7f.
---
 .../fam-in-union-alone-in-struct-2.c          | 22 ++++++++++++++-----
 1 file changed, 17 insertions(+), 5 deletions(-)

--
2.45.2

Comments

Sam James July 31, 2024, 10:56 a.m. UTC | #1 
"Kewen.Lin" <linkw@linux.ibm.com> writes:

> Hi,
>
> As Andrew pointed out in PR116148, fam-in-union-alone-in-struct-2.c
> was designed for little-endian, the recent commit r15-2403 made it
> be tested with running on BE and PR116148 got exposed.
>
> This patch is to adjust the expected data for members in with_fam_2_v
> and with_fam_3_v by considering endianness, also update with_fam_3_v.b[1]
> from 0x5f6f7f7f to 0x5f6f7f8f to avoid two "7f"s.
>
> Tested on powerpc64-linux-gnu P8/P9 and powerpc64le-linux-gnu P9/P10.
>
> Is it ok for trunk?

I can't approve it but LGTM & thanks for doing it. Maybe give Qing at
least the rest of the day to comment given it's theirs.

>
> BR,
> Kewen

thanks,
sam
Qing Zhao July 31, 2024, 6:59 p.m. UTC | #2 
Hi, Kewen,

Thanks a lot for fixing this testing case issue.
Yes, the change LGTM though I can’t approve it. 

Qing

> On Jul 31, 2024, at 05:22, Kewen.Lin <linkw@linux.ibm.com> wrote:
> 
> Hi,
> 
> As Andrew pointed out in PR116148, fam-in-union-alone-in-struct-2.c
> was designed for little-endian, the recent commit r15-2403 made it
> be tested with running on BE and PR116148 got exposed.
> 
> This patch is to adjust the expected data for members in with_fam_2_v
> and with_fam_3_v by considering endianness, also update with_fam_3_v.b[1]
> from 0x5f6f7f7f to 0x5f6f7f8f to avoid two "7f"s.
> 
> Tested on powerpc64-linux-gnu P8/P9 and powerpc64le-linux-gnu P9/P10.
> 
> Is it ok for trunk?
> 
> BR,
> Kewen
> -----
> 	PR testsuite/116148
> 
> gcc/testsuite/ChangeLog:
> 
> 	* c-c++-common/fam-in-union-alone-in-struct-2.c: Define macros
> 	WITH_FAM_2_V_B[03] and WITH_FAM_3_V_A[07] as endianness, update the
> 	checking with these macros and initialize with_fam_3_v.b[1] with
> 	0x5f6f7f8f instead of 0x5f6f7f7f.
> ---
> .../fam-in-union-alone-in-struct-2.c          | 22 ++++++++++++++-----
> 1 file changed, 17 insertions(+), 5 deletions(-)
> 
> diff --git a/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-2.c b/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-2.c
> index 93f9d5128f6..7845a7fbab3 100644
> --- a/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-2.c
> +++ b/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-2.c
> @@ -16,7 +16,7 @@ union with_fam_2 {
> union with_fam_3 {
>   char a[];
>   int b[];
> -} with_fam_3_v = {.b = {0x1f2f3f4f, 0x5f6f7f7f}};
> +} with_fam_3_v = {.b = {0x1f2f3f4f, 0x5f6f7f8f}};
> 
> struct only_fam {
>   int b[];
> @@ -28,16 +28,28 @@ struct only_fam_2 {
>   int b[];
> } only_fam_2_v = {{7, 11}};
> 
> +#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
> +#define WITH_FAM_2_V_B0 0x4f
> +#define WITH_FAM_2_V_B3 0x1f
> +#define WITH_FAM_3_V_A0 0x4f
> +#define WITH_FAM_3_V_A7 0x5f
> +#else
> +#define WITH_FAM_2_V_B0 0x1f
> +#define WITH_FAM_2_V_B3 0x4f
> +#define WITH_FAM_3_V_A0 0x1f
> +#define WITH_FAM_3_V_A7 0x8f
> +#endif
> +
> int main ()
> {
>   if (with_fam_1_v.b[3] != 4
>       || with_fam_1_v.b[0] != 1)
>     __builtin_abort ();
> -  if (with_fam_2_v.b[3] != 0x1f
> -      || with_fam_2_v.b[0] != 0x4f)
> +  if (with_fam_2_v.b[3] != WITH_FAM_2_V_B3
> +      || with_fam_2_v.b[0] != WITH_FAM_2_V_B0)
>     __builtin_abort ();
> -  if (with_fam_3_v.a[0] != 0x4f
> -      || with_fam_3_v.a[7] != 0x5f)
> +  if (with_fam_3_v.a[0] != WITH_FAM_3_V_A0
> +      || with_fam_3_v.a[7] != WITH_FAM_3_V_A7)
>     __builtin_abort ();
>   if (only_fam_v.b[0] != 7
>       || only_fam_v.b[1] != 11)
> --
> 2.45.2
Richard Biener Aug. 1, 2024, 7:04 a.m. UTC | #3 
On Wed, Jul 31, 2024 at 9:00 PM Qing Zhao <qing.zhao@oracle.com> wrote:
>
> Hi, Kewen,
>
> Thanks a lot for fixing this testing case issue.
> Yes, the change LGTM though I can’t approve it.

OK.

Richard.

> Qing
>
> > On Jul 31, 2024, at 05:22, Kewen.Lin <linkw@linux.ibm.com> wrote:
> >
> > Hi,
> >
> > As Andrew pointed out in PR116148, fam-in-union-alone-in-struct-2.c
> > was designed for little-endian, the recent commit r15-2403 made it
> > be tested with running on BE and PR116148 got exposed.
> >
> > This patch is to adjust the expected data for members in with_fam_2_v
> > and with_fam_3_v by considering endianness, also update with_fam_3_v.b[1]
> > from 0x5f6f7f7f to 0x5f6f7f8f to avoid two "7f"s.
> >
> > Tested on powerpc64-linux-gnu P8/P9 and powerpc64le-linux-gnu P9/P10.
> >
> > Is it ok for trunk?
> >
> > BR,
> > Kewen
> > -----
> >       PR testsuite/116148
> >
> > gcc/testsuite/ChangeLog:
> >
> >       * c-c++-common/fam-in-union-alone-in-struct-2.c: Define macros
> >       WITH_FAM_2_V_B[03] and WITH_FAM_3_V_A[07] as endianness, update the
> >       checking with these macros and initialize with_fam_3_v.b[1] with
> >       0x5f6f7f8f instead of 0x5f6f7f7f.
> > ---
> > .../fam-in-union-alone-in-struct-2.c          | 22 ++++++++++++++-----
> > 1 file changed, 17 insertions(+), 5 deletions(-)
> >
> > diff --git a/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-2.c b/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-2.c
> > index 93f9d5128f6..7845a7fbab3 100644
> > --- a/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-2.c
> > +++ b/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-2.c
> > @@ -16,7 +16,7 @@ union with_fam_2 {
> > union with_fam_3 {
> >   char a[];
> >   int b[];
> > -} with_fam_3_v = {.b = {0x1f2f3f4f, 0x5f6f7f7f}};
> > +} with_fam_3_v = {.b = {0x1f2f3f4f, 0x5f6f7f8f}};
> >
> > struct only_fam {
> >   int b[];
> > @@ -28,16 +28,28 @@ struct only_fam_2 {
> >   int b[];
> > } only_fam_2_v = {{7, 11}};
> >
> > +#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
> > +#define WITH_FAM_2_V_B0 0x4f
> > +#define WITH_FAM_2_V_B3 0x1f
> > +#define WITH_FAM_3_V_A0 0x4f
> > +#define WITH_FAM_3_V_A7 0x5f
> > +#else
> > +#define WITH_FAM_2_V_B0 0x1f
> > +#define WITH_FAM_2_V_B3 0x4f
> > +#define WITH_FAM_3_V_A0 0x1f
> > +#define WITH_FAM_3_V_A7 0x8f
> > +#endif
> > +
> > int main ()
> > {
> >   if (with_fam_1_v.b[3] != 4
> >       || with_fam_1_v.b[0] != 1)
> >     __builtin_abort ();
> > -  if (with_fam_2_v.b[3] != 0x1f
> > -      || with_fam_2_v.b[0] != 0x4f)
> > +  if (with_fam_2_v.b[3] != WITH_FAM_2_V_B3
> > +      || with_fam_2_v.b[0] != WITH_FAM_2_V_B0)
> >     __builtin_abort ();
> > -  if (with_fam_3_v.a[0] != 0x4f
> > -      || with_fam_3_v.a[7] != 0x5f)
> > +  if (with_fam_3_v.a[0] != WITH_FAM_3_V_A0
> > +      || with_fam_3_v.a[7] != WITH_FAM_3_V_A7)
> >     __builtin_abort ();
> >   if (only_fam_v.b[0] != 7
> >       || only_fam_v.b[1] != 11)
> > --
> > 2.45.2
>
Kewen.Lin Aug. 2, 2024, 12:33 a.m. UTC | #4 
on 2024/8/1 15:04, Richard Biener wrote:
> On Wed, Jul 31, 2024 at 9:00 PM Qing Zhao <qing.zhao@oracle.com> wrote:
>>
>> Hi, Kewen,
>>
>> Thanks a lot for fixing this testing case issue.
>> Yes, the change LGTM though I can’t approve it.
> 
> OK.

Thanks to all, pushed as r15-2658.

BR,
Kewen

> 
> Richard.
> 
>> Qing
>>
>>> On Jul 31, 2024, at 05:22, Kewen.Lin <linkw@linux.ibm.com> wrote:
>>>
>>> Hi,
>>>
>>> As Andrew pointed out in PR116148, fam-in-union-alone-in-struct-2.c
>>> was designed for little-endian, the recent commit r15-2403 made it
>>> be tested with running on BE and PR116148 got exposed.
>>>
>>> This patch is to adjust the expected data for members in with_fam_2_v
>>> and with_fam_3_v by considering endianness, also update with_fam_3_v.b[1]
>>> from 0x5f6f7f7f to 0x5f6f7f8f to avoid two "7f"s.
>>>
>>> Tested on powerpc64-linux-gnu P8/P9 and powerpc64le-linux-gnu P9/P10.
>>>
>>> Is it ok for trunk?
>>>
>>> BR,
>>> Kewen
>>> -----
>>>       PR testsuite/116148
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>>       * c-c++-common/fam-in-union-alone-in-struct-2.c: Define macros
>>>       WITH_FAM_2_V_B[03] and WITH_FAM_3_V_A[07] as endianness, update the
>>>       checking with these macros and initialize with_fam_3_v.b[1] with
>>>       0x5f6f7f8f instead of 0x5f6f7f7f.
>>> ---
>>> .../fam-in-union-alone-in-struct-2.c          | 22 ++++++++++++++-----
>>> 1 file changed, 17 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-2.c b/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-2.c
>>> index 93f9d5128f6..7845a7fbab3 100644
>>> --- a/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-2.c
>>> +++ b/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-2.c
>>> @@ -16,7 +16,7 @@ union with_fam_2 {
>>> union with_fam_3 {
>>>   char a[];
>>>   int b[];
>>> -} with_fam_3_v = {.b = {0x1f2f3f4f, 0x5f6f7f7f}};
>>> +} with_fam_3_v = {.b = {0x1f2f3f4f, 0x5f6f7f8f}};
>>>
>>> struct only_fam {
>>>   int b[];
>>> @@ -28,16 +28,28 @@ struct only_fam_2 {
>>>   int b[];
>>> } only_fam_2_v = {{7, 11}};
>>>
>>> +#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
>>> +#define WITH_FAM_2_V_B0 0x4f
>>> +#define WITH_FAM_2_V_B3 0x1f
>>> +#define WITH_FAM_3_V_A0 0x4f
>>> +#define WITH_FAM_3_V_A7 0x5f
>>> +#else
>>> +#define WITH_FAM_2_V_B0 0x1f
>>> +#define WITH_FAM_2_V_B3 0x4f
>>> +#define WITH_FAM_3_V_A0 0x1f
>>> +#define WITH_FAM_3_V_A7 0x8f
>>> +#endif
>>> +
>>> int main ()
>>> {
>>>   if (with_fam_1_v.b[3] != 4
>>>       || with_fam_1_v.b[0] != 1)
>>>     __builtin_abort ();
>>> -  if (with_fam_2_v.b[3] != 0x1f
>>> -      || with_fam_2_v.b[0] != 0x4f)
>>> +  if (with_fam_2_v.b[3] != WITH_FAM_2_V_B3
>>> +      || with_fam_2_v.b[0] != WITH_FAM_2_V_B0)
>>>     __builtin_abort ();
>>> -  if (with_fam_3_v.a[0] != 0x4f
>>> -      || with_fam_3_v.a[7] != 0x5f)
>>> +  if (with_fam_3_v.a[0] != WITH_FAM_3_V_A0
>>> +      || with_fam_3_v.a[7] != WITH_FAM_3_V_A7)
>>>     __builtin_abort ();
>>>   if (only_fam_v.b[0] != 7
>>>       || only_fam_v.b[1] != 11)
>>> --
>>> 2.45.2
>>
diff mbox series

Patch

diff --git a/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-2.c b/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-2.c
index 93f9d5128f6..7845a7fbab3 100644
--- a/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-2.c
+++ b/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-2.c
@@ -16,7 +16,7 @@  union with_fam_2 {
 union with_fam_3 {
   char a[];
   int b[];
-} with_fam_3_v = {.b = {0x1f2f3f4f, 0x5f6f7f7f}};
+} with_fam_3_v = {.b = {0x1f2f3f4f, 0x5f6f7f8f}};

 struct only_fam {
   int b[];
@@ -28,16 +28,28 @@  struct only_fam_2 {
   int b[];
 } only_fam_2_v = {{7, 11}};

+#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
+#define WITH_FAM_2_V_B0 0x4f
+#define WITH_FAM_2_V_B3 0x1f
+#define WITH_FAM_3_V_A0 0x4f
+#define WITH_FAM_3_V_A7 0x5f
+#else
+#define WITH_FAM_2_V_B0 0x1f
+#define WITH_FAM_2_V_B3 0x4f
+#define WITH_FAM_3_V_A0 0x1f
+#define WITH_FAM_3_V_A7 0x8f
+#endif
+
 int main ()
 {
   if (with_fam_1_v.b[3] != 4
       || with_fam_1_v.b[0] != 1)
     __builtin_abort ();
-  if (with_fam_2_v.b[3] != 0x1f
-      || with_fam_2_v.b[0] != 0x4f)
+  if (with_fam_2_v.b[3] != WITH_FAM_2_V_B3
+      || with_fam_2_v.b[0] != WITH_FAM_2_V_B0)
     __builtin_abort ();
-  if (with_fam_3_v.a[0] != 0x4f
-      || with_fam_3_v.a[7] != 0x5f)
+  if (with_fam_3_v.a[0] != WITH_FAM_3_V_A0
+      || with_fam_3_v.a[7] != WITH_FAM_3_V_A7)
     __builtin_abort ();
   if (only_fam_v.b[0] != 7
       || only_fam_v.b[1] != 11)