* [PATCH] aarch64: Fix test_dfp_17.c for big-endian [PR 107604] @ 2022-11-22 9:01 Christophe Lyon 2022-11-22 10:57 ` Richard Sandiford 2022-11-22 11:09 ` Richard Earnshaw 0 siblings, 2 replies; 8+ messages in thread From: Christophe Lyon @ 2022-11-22 9:01 UTC (permalink / raw) To: gcc-patches; +Cc: Christophe Lyon gcc.target/aarch64/aapcs64/test_dfp_17.c has been failing on big-endian, because the _Decimal32 on-stack argument is not padded in the same direction depending on endianness. This patch fixes the testcase so that it expects the argument in the right stack location, similarly to what other tests do in the same directory. gcc/testsuite/ChangeLog: PR target/107604 * gcc.target/aarch64/aapcs64/test_dfp_17.c: Fix for big-endian. --- gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c index 22dc462bf7c..3c45f715cf7 100644 --- a/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c +++ b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c @@ -32,6 +32,10 @@ struct z b = { 9.0dd, 10.0dd, 11.0dd, 12.0dd }; ANON(struct z, a, D1) ANON(struct z, b, STACK) ANON(int , 5, W0) +#ifndef __AAPCS64_BIG_ENDIAN__ ANON(_Decimal32, f1, STACK+32) /* Note: no promotion to _Decimal64. */ +#else + ANON(_Decimal32, f1, STACK+36) /* Note: no promotion to _Decimal64. */ +#endif LAST_ANON(_Decimal64, 0.5dd, STACK+40) #endif -- 2.34.1 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] aarch64: Fix test_dfp_17.c for big-endian [PR 107604] 2022-11-22 9:01 [PATCH] aarch64: Fix test_dfp_17.c for big-endian [PR 107604] Christophe Lyon @ 2022-11-22 10:57 ` Richard Sandiford 2022-11-22 11:09 ` Richard Earnshaw 1 sibling, 0 replies; 8+ messages in thread From: Richard Sandiford @ 2022-11-22 10:57 UTC (permalink / raw) To: Christophe Lyon via Gcc-patches; +Cc: Christophe Lyon Christophe Lyon via Gcc-patches <gcc-patches@gcc.gnu.org> writes: > gcc.target/aarch64/aapcs64/test_dfp_17.c has been failing on > big-endian, because the _Decimal32 on-stack argument is not padded in > the same direction depending on endianness. > > This patch fixes the testcase so that it expects the argument in the > right stack location, similarly to what other tests do in the same > directory. > > gcc/testsuite/ChangeLog: > > PR target/107604 > * gcc.target/aarch64/aapcs64/test_dfp_17.c: Fix for big-endian. OK, thanks. Richard > --- > gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c > index 22dc462bf7c..3c45f715cf7 100644 > --- a/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c > +++ b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c > @@ -32,6 +32,10 @@ struct z b = { 9.0dd, 10.0dd, 11.0dd, 12.0dd }; > ANON(struct z, a, D1) > ANON(struct z, b, STACK) > ANON(int , 5, W0) > +#ifndef __AAPCS64_BIG_ENDIAN__ > ANON(_Decimal32, f1, STACK+32) /* Note: no promotion to _Decimal64. */ > +#else > + ANON(_Decimal32, f1, STACK+36) /* Note: no promotion to _Decimal64. */ > +#endif > LAST_ANON(_Decimal64, 0.5dd, STACK+40) > #endif ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] aarch64: Fix test_dfp_17.c for big-endian [PR 107604] 2022-11-22 9:01 [PATCH] aarch64: Fix test_dfp_17.c for big-endian [PR 107604] Christophe Lyon 2022-11-22 10:57 ` Richard Sandiford @ 2022-11-22 11:09 ` Richard Earnshaw 2022-11-22 11:21 ` Richard Sandiford 1 sibling, 1 reply; 8+ messages in thread From: Richard Earnshaw @ 2022-11-22 11:09 UTC (permalink / raw) To: Christophe Lyon, gcc-patches On 22/11/2022 09:01, Christophe Lyon via Gcc-patches wrote: > gcc.target/aarch64/aapcs64/test_dfp_17.c has been failing on > big-endian, because the _Decimal32 on-stack argument is not padded in > the same direction depending on endianness. > > This patch fixes the testcase so that it expects the argument in the > right stack location, similarly to what other tests do in the same > directory. > > gcc/testsuite/ChangeLog: > > PR target/107604 > * gcc.target/aarch64/aapcs64/test_dfp_17.c: Fix for big-endian. > --- > gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c > index 22dc462bf7c..3c45f715cf7 100644 > --- a/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c > +++ b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c > @@ -32,6 +32,10 @@ struct z b = { 9.0dd, 10.0dd, 11.0dd, 12.0dd }; > ANON(struct z, a, D1) > ANON(struct z, b, STACK) > ANON(int , 5, W0) > +#ifndef __AAPCS64_BIG_ENDIAN__ > ANON(_Decimal32, f1, STACK+32) /* Note: no promotion to _Decimal64. */ > +#else > + ANON(_Decimal32, f1, STACK+36) /* Note: no promotion to _Decimal64. */ > +#endif > LAST_ANON(_Decimal64, 0.5dd, STACK+40) > #endif Why would a Decimal32 change stack placement based on the endianness? Isn't it a 4-byte object? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] aarch64: Fix test_dfp_17.c for big-endian [PR 107604] 2022-11-22 11:09 ` Richard Earnshaw @ 2022-11-22 11:21 ` Richard Sandiford 2022-11-22 11:33 ` Richard Earnshaw 0 siblings, 1 reply; 8+ messages in thread From: Richard Sandiford @ 2022-11-22 11:21 UTC (permalink / raw) To: Richard Earnshaw via Gcc-patches; +Cc: Christophe Lyon, Richard Earnshaw Richard Earnshaw via Gcc-patches <gcc-patches@gcc.gnu.org> writes: > On 22/11/2022 09:01, Christophe Lyon via Gcc-patches wrote: >> gcc.target/aarch64/aapcs64/test_dfp_17.c has been failing on >> big-endian, because the _Decimal32 on-stack argument is not padded in >> the same direction depending on endianness. >> >> This patch fixes the testcase so that it expects the argument in the >> right stack location, similarly to what other tests do in the same >> directory. >> >> gcc/testsuite/ChangeLog: >> >> PR target/107604 >> * gcc.target/aarch64/aapcs64/test_dfp_17.c: Fix for big-endian. >> --- >> gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c | 4 ++++ >> 1 file changed, 4 insertions(+) >> >> diff --git a/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c >> index 22dc462bf7c..3c45f715cf7 100644 >> --- a/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c >> +++ b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c >> @@ -32,6 +32,10 @@ struct z b = { 9.0dd, 10.0dd, 11.0dd, 12.0dd }; >> ANON(struct z, a, D1) >> ANON(struct z, b, STACK) >> ANON(int , 5, W0) >> +#ifndef __AAPCS64_BIG_ENDIAN__ >> ANON(_Decimal32, f1, STACK+32) /* Note: no promotion to _Decimal64. */ >> +#else >> + ANON(_Decimal32, f1, STACK+36) /* Note: no promotion to _Decimal64. */ >> +#endif >> LAST_ANON(_Decimal64, 0.5dd, STACK+40) >> #endif > > Why would a Decimal32 change stack placement based on the endianness? > Isn't it a 4-byte object? Yes, but PARM_BOUNDARY (64) sets a minimum alignment for all stack arguments. Richard ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] aarch64: Fix test_dfp_17.c for big-endian [PR 107604] 2022-11-22 11:21 ` Richard Sandiford @ 2022-11-22 11:33 ` Richard Earnshaw 2022-11-22 13:07 ` Christophe Lyon 2022-11-22 13:09 ` Christophe Lyon 0 siblings, 2 replies; 8+ messages in thread From: Richard Earnshaw @ 2022-11-22 11:33 UTC (permalink / raw) To: Richard Earnshaw via Gcc-patches, Christophe Lyon, richard.sandiford On 22/11/2022 11:21, Richard Sandiford wrote: > Richard Earnshaw via Gcc-patches <gcc-patches@gcc.gnu.org> writes: >> On 22/11/2022 09:01, Christophe Lyon via Gcc-patches wrote: >>> gcc.target/aarch64/aapcs64/test_dfp_17.c has been failing on >>> big-endian, because the _Decimal32 on-stack argument is not padded in >>> the same direction depending on endianness. >>> >>> This patch fixes the testcase so that it expects the argument in the >>> right stack location, similarly to what other tests do in the same >>> directory. >>> >>> gcc/testsuite/ChangeLog: >>> >>> PR target/107604 >>> * gcc.target/aarch64/aapcs64/test_dfp_17.c: Fix for big-endian. >>> --- >>> gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c | 4 ++++ >>> 1 file changed, 4 insertions(+) >>> >>> diff --git a/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c >>> index 22dc462bf7c..3c45f715cf7 100644 >>> --- a/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c >>> +++ b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c >>> @@ -32,6 +32,10 @@ struct z b = { 9.0dd, 10.0dd, 11.0dd, 12.0dd }; >>> ANON(struct z, a, D1) >>> ANON(struct z, b, STACK) >>> ANON(int , 5, W0) >>> +#ifndef __AAPCS64_BIG_ENDIAN__ >>> ANON(_Decimal32, f1, STACK+32) /* Note: no promotion to _Decimal64. */ >>> +#else >>> + ANON(_Decimal32, f1, STACK+36) /* Note: no promotion to _Decimal64. */ >>> +#endif >>> LAST_ANON(_Decimal64, 0.5dd, STACK+40) >>> #endif >> >> Why would a Decimal32 change stack placement based on the endianness? >> Isn't it a 4-byte object? > > Yes, but PARM_BOUNDARY (64) sets a minimum alignment for all stack arguments. > > Richard Ah, OK. I wonder if we should have a new macro in the tests, something like ANON_PADDED to describe this case and that works things out more automagically for big-endian. I notice the new ANON definition is not correctly indented. R. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] aarch64: Fix test_dfp_17.c for big-endian [PR 107604] 2022-11-22 11:33 ` Richard Earnshaw @ 2022-11-22 13:07 ` Christophe Lyon 2022-11-22 13:09 ` Christophe Lyon 1 sibling, 0 replies; 8+ messages in thread From: Christophe Lyon @ 2022-11-22 13:07 UTC (permalink / raw) To: Richard Earnshaw, Richard Earnshaw via Gcc-patches, richard.sandiford On 11/22/22 12:33, Richard Earnshaw wrote: > > > On 22/11/2022 11:21, Richard Sandiford wrote: >> Richard Earnshaw via Gcc-patches <gcc-patches@gcc.gnu.org> writes: >>> On 22/11/2022 09:01, Christophe Lyon via Gcc-patches wrote: >>>> gcc.target/aarch64/aapcs64/test_dfp_17.c has been failing on >>>> big-endian, because the _Decimal32 on-stack argument is not padded in >>>> the same direction depending on endianness. >>>> >>>> This patch fixes the testcase so that it expects the argument in the >>>> right stack location, similarly to what other tests do in the same >>>> directory. >>>> >>>> gcc/testsuite/ChangeLog: >>>> >>>> PR target/107604 >>>> * gcc.target/aarch64/aapcs64/test_dfp_17.c: Fix for big-endian. >>>> --- >>>> gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c | 4 ++++ >>>> 1 file changed, 4 insertions(+) >>>> >>>> diff --git a/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c >>>> b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c >>>> index 22dc462bf7c..3c45f715cf7 100644 >>>> --- a/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c >>>> +++ b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c >>>> @@ -32,6 +32,10 @@ struct z b = { 9.0dd, 10.0dd, 11.0dd, 12.0dd }; >>>> ANON(struct z, a, D1) >>>> ANON(struct z, b, STACK) >>>> ANON(int , 5, W0) >>>> +#ifndef __AAPCS64_BIG_ENDIAN__ >>>> ANON(_Decimal32, f1, STACK+32) /* Note: no promotion to >>>> _Decimal64. */ >>>> +#else >>>> + ANON(_Decimal32, f1, STACK+36) /* Note: no promotion to >>>> _Decimal64. */ >>>> +#endif >>>> LAST_ANON(_Decimal64, 0.5dd, STACK+40) >>>> #endif >>> >>> Why would a Decimal32 change stack placement based on the endianness? >>> Isn't it a 4-byte object? >> >> Yes, but PARM_BOUNDARY (64) sets a minimum alignment for all stack >> arguments. >> >> Richard > > Ah, OK. Indeed, it was not immediately obvious to me either when looking at aarch64_layout_arg. aarch64_function_arg_padding comes into play, too. > > I wonder if we should have a new macro in the tests, something like > ANON_PADDED to describe this case and that works things out more > automagically for big-endian. Maybe, there are quite a few tests under aapcs64 which have a similar #ifndef __AAPCS64_BIG_ENDIAN__ > I notice the new ANON definition is not correctly indented. > > R. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] aarch64: Fix test_dfp_17.c for big-endian [PR 107604] 2022-11-22 11:33 ` Richard Earnshaw 2022-11-22 13:07 ` Christophe Lyon @ 2022-11-22 13:09 ` Christophe Lyon 2022-11-22 14:03 ` Richard Earnshaw 1 sibling, 1 reply; 8+ messages in thread From: Christophe Lyon @ 2022-11-22 13:09 UTC (permalink / raw) To: Richard Earnshaw, Richard Earnshaw via Gcc-patches, richard.sandiford On 11/22/22 12:33, Richard Earnshaw wrote: > > > On 22/11/2022 11:21, Richard Sandiford wrote: >> Richard Earnshaw via Gcc-patches <gcc-patches@gcc.gnu.org> writes: >>> On 22/11/2022 09:01, Christophe Lyon via Gcc-patches wrote: >>>> gcc.target/aarch64/aapcs64/test_dfp_17.c has been failing on >>>> big-endian, because the _Decimal32 on-stack argument is not >>>> padded in the same direction depending on endianness. >>>> >>>> This patch fixes the testcase so that it expects the argument >>>> in the right stack location, similarly to what other tests do >>>> in the same directory. >>>> >>>> gcc/testsuite/ChangeLog: >>>> >>>> PR target/107604 * gcc.target/aarch64/aapcs64/test_dfp_17.c: >>>> Fix for big-endian. --- >>>> gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c | 4 >>>> ++++ 1 file changed, 4 insertions(+) >>>> >>>> diff --git >>>> a/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c >>>> b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c index >>>> 22dc462bf7c..3c45f715cf7 100644 --- >>>> a/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c +++ >>>> b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c @@ >>>> -32,6 +32,10 @@ struct z b = { 9.0dd, 10.0dd, 11.0dd, 12.0dd >>>> }; ANON(struct z, a, D1) ANON(struct z, b, STACK) ANON(int , 5, >>>> W0) +#ifndef __AAPCS64_BIG_ENDIAN__ ANON(_Decimal32, f1, >>>> STACK+32) /* Note: no promotion to _Decimal64. */ +#else + >>>> ANON(_Decimal32, f1, STACK+36) /* Note: no promotion to >>>> _Decimal64. */ +#endif LAST_ANON(_Decimal64, 0.5dd, STACK+40) >>>> #endif >>> >>> Why would a Decimal32 change stack placement based on the >>> endianness? Isn't it a 4-byte object? >> >> Yes, but PARM_BOUNDARY (64) sets a minimum alignment for all stack >> arguments. >> >> Richard > > Ah, OK. Indeed, it was not immediately obvious to me either, when looking at aarch64_layout_arg. aarch64_function_arg_padding comes into play, too. > > I wonder if we should have a new macro in the tests, something like > ANON_PADDED to describe this case and that works things out more > automagically for big-endian. Maybe. There are many other tests under aapcs64/ which have a similar #ifndef __AAPCS64_BIG_ENDIAN__ > I notice the new ANON definition is not correctly indented. It looks OK on my side (2 spaces). Thanks, Christophe > > R. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] aarch64: Fix test_dfp_17.c for big-endian [PR 107604] 2022-11-22 13:09 ` Christophe Lyon @ 2022-11-22 14:03 ` Richard Earnshaw 0 siblings, 0 replies; 8+ messages in thread From: Richard Earnshaw @ 2022-11-22 14:03 UTC (permalink / raw) To: Christophe Lyon, Richard Earnshaw via Gcc-patches, richard.sandiford On 22/11/2022 13:09, Christophe Lyon wrote: > > > On 11/22/22 12:33, Richard Earnshaw wrote: >> >> >> On 22/11/2022 11:21, Richard Sandiford wrote: >>> Richard Earnshaw via Gcc-patches <gcc-patches@gcc.gnu.org> writes: >>>> On 22/11/2022 09:01, Christophe Lyon via Gcc-patches wrote: >>>>> gcc.target/aarch64/aapcs64/test_dfp_17.c has been failing on >>>>> big-endian, because the _Decimal32 on-stack argument is not >>>>> padded in the same direction depending on endianness. >>>>> >>>>> This patch fixes the testcase so that it expects the argument >>>>> in the right stack location, similarly to what other tests do >>>>> in the same directory. >>>>> >>>>> gcc/testsuite/ChangeLog: >>>>> >>>>> PR target/107604 * gcc.target/aarch64/aapcs64/test_dfp_17.c: >>>>> Fix for big-endian. --- >>>>> gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c | 4 >>>>> ++++ 1 file changed, 4 insertions(+) >>>>> >>>>> diff --git >>>>> a/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c >>>>> b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c index >>>>> 22dc462bf7c..3c45f715cf7 100644 --- >>>>> a/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c +++ >>>>> b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c @@ >>>>> -32,6 +32,10 @@ struct z b = { 9.0dd, 10.0dd, 11.0dd, 12.0dd >>>>> }; ANON(struct z, a, D1) ANON(struct z, b, STACK) ANON(int , 5, >>>>> W0) +#ifndef __AAPCS64_BIG_ENDIAN__ ANON(_Decimal32, f1, >>>>> STACK+32) /* Note: no promotion to _Decimal64. */ +#else + >>>>> ANON(_Decimal32, f1, STACK+36) /* Note: no promotion to >>>>> _Decimal64. */ +#endif LAST_ANON(_Decimal64, 0.5dd, STACK+40) #endif >>>> >>>> Why would a Decimal32 change stack placement based on the >>>> endianness? Isn't it a 4-byte object? >>> >>> Yes, but PARM_BOUNDARY (64) sets a minimum alignment for all stack >>> arguments. >>> >>> Richard >> >> Ah, OK. > Indeed, it was not immediately obvious to me either, when looking at > aarch64_layout_arg. aarch64_function_arg_padding comes into play, too. > >> >> I wonder if we should have a new macro in the tests, something like >> ANON_PADDED to describe this case and that works things out more >> automagically for big-endian. > Maybe. There are many other tests under aapcs64/ which have a similar > #ifndef __AAPCS64_BIG_ENDIAN__ > Yes, it could be used to clean all those up as well. > >> I notice the new ANON definition is not correctly indented. > It looks OK on my side (2 spaces). Never mind then, it must be a quirk of how the diff is displayed. > > Thanks, > > Christophe > >> >> R. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-11-22 16:32 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-11-22 9:01 [PATCH] aarch64: Fix test_dfp_17.c for big-endian [PR 107604] Christophe Lyon 2022-11-22 10:57 ` Richard Sandiford 2022-11-22 11:09 ` Richard Earnshaw 2022-11-22 11:21 ` Richard Sandiford 2022-11-22 11:33 ` Richard Earnshaw 2022-11-22 13:07 ` Christophe Lyon 2022-11-22 13:09 ` Christophe Lyon 2022-11-22 14:03 ` 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).