[pushed] [gdb/testsuite] Fix gdb.arch/altivec-regs.exp with gcc 4.8.5

[pushed] [gdb/testsuite] Fix gdb.arch/altivec-regs.exp with gcc 4.8.5

[Tom de Vries]

On powerpc64le-linux, using gcc 4.8.5, I run into:
...
(gdb) PASS: gdb.arch/altivec-regs.exp: next (1)
next^M
11        c = vec_add (a, b);^M
(gdb) PASS: gdb.arch/altivec-regs.exp: next (2)
print/x a^M
$67 = {0xfefefefe, 0xfefefefe, 0xfefefefe, 0xfefefefe}^M
(gdb) FAIL: gdb.arch/altivec-regs.exp: print vector parameter a
...

Looking at the disassembly and the debug info, it's clear why there's
a FAIL.

The debug info says that the variable can be found at some stack location, but
the instructions don't seem to be writing there.

We can work around this by marking variable a volatile.  Likewise for b.

Note that marking the variables as volatile doesn't change the location
information.

Tested on power64le-linux.
---
 gdb/testsuite/gdb.arch/altivec-regs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.arch/altivec-regs.c b/gdb/testsuite/gdb.arch/altivec-regs.c
index 4d4fe3f5dbb..8f3b729fe3f 100644
--- a/gdb/testsuite/gdb.arch/altivec-regs.c
+++ b/gdb/testsuite/gdb.arch/altivec-regs.c
@@ -2,7 +2,7 @@
 #include <stdio.h>
 
 vector unsigned int
-vector_fun (vector unsigned int a, vector unsigned int b)
+vector_fun (volatile vector unsigned int a, volatile vector unsigned int b)
 {
   vector unsigned int c;
   a = ((vector unsigned int) vec_splat_u8(2));

base-commit: 2650ea9730e31fc5c9111afc1a689dbca76707f5
-- 
2.35.3

Re: [pushed] [gdb/testsuite] Fix gdb.arch/altivec-regs.exp with gcc 4.8.5

[Carl Love]

Tom:

On Mon, 2022-11-28 at 13:57 +0100, Tom de Vries wrote:
> On powerpc64le-linux, using gcc 4.8.5, I run into:
> ...
> (gdb) PASS: gdb.arch/altivec-regs.exp: next (1)
> next^M
> 11        c = vec_add (a, b);^M
> (gdb) PASS: gdb.arch/altivec-regs.exp: next (2)
> print/x a^M
> $67 = {0xfefefefe, 0xfefefefe, 0xfefefefe, 0xfefefefe}^M
> (gdb) FAIL: gdb.arch/altivec-regs.exp: print vector parameter a
> ...
> 
> Looking at the disassembly and the debug info, it's clear why there's
> a FAIL.
> 
> The debug info says that the variable can be found at some stack
> location, but
> the instructions don't seem to be writing there.
> 
> We can work around this by marking variable a volatile.  Likewise for
> b.
> 
> Note that marking the variables as volatile doesn't change the
> location
> information.
> 
> Tested on power64le-linux.
> ---
>  gdb/testsuite/gdb.arch/altivec-regs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gdb/testsuite/gdb.arch/altivec-regs.c
> b/gdb/testsuite/gdb.arch/altivec-regs.c
> index 4d4fe3f5dbb..8f3b729fe3f 100644
> --- a/gdb/testsuite/gdb.arch/altivec-regs.c
> +++ b/gdb/testsuite/gdb.arch/altivec-regs.c
> @@ -2,7 +2,7 @@
>  #include <stdio.h>
> 
>  vector unsigned int
> -vector_fun (vector unsigned int a, vector unsigned int b)
> +vector_fun (volatile vector unsigned int a, volatile vector unsigned
> int b)
>  {
>    vector unsigned int c;
>    a = ((vector unsigned int) vec_splat_u8(2));
> 
> base-commit: 2650ea9730e31fc5c9111afc1a689dbca76707f5

I ran this test case before and after your commit on my Power 10 and my
Power 9 box.  I did not see a failure before or after the commit on
either machine.  The fix looks fine to me as it doesn't change the
behavior on Power 9 or Power 10 that I can see.

                    Carl 

Re: [pushed] [gdb/testsuite] Fix gdb.arch/altivec-regs.exp with gcc 4.8.5

[Tom de Vries]

On 11/28/22 18:02, Carl Love wrote:
> Tom:
> 
> On Mon, 2022-11-28 at 13:57 +0100, Tom de Vries wrote:
>> On powerpc64le-linux, using gcc 4.8.5, I run into:
>> ...
>> (gdb) PASS: gdb.arch/altivec-regs.exp: next (1)
>> next^M
>> 11        c = vec_add (a, b);^M
>> (gdb) PASS: gdb.arch/altivec-regs.exp: next (2)
>> print/x a^M
>> $67 = {0xfefefefe, 0xfefefefe, 0xfefefefe, 0xfefefefe}^M
>> (gdb) FAIL: gdb.arch/altivec-regs.exp: print vector parameter a
>> ...
>>
>> Looking at the disassembly and the debug info, it's clear why there's
>> a FAIL.
>>
>> The debug info says that the variable can be found at some stack
>> location, but
>> the instructions don't seem to be writing there.
>>
>> We can work around this by marking variable a volatile.  Likewise for
>> b.
>>
>> Note that marking the variables as volatile doesn't change the
>> location
>> information.
>>
>> Tested on power64le-linux.
>> ---
>>   gdb/testsuite/gdb.arch/altivec-regs.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/gdb/testsuite/gdb.arch/altivec-regs.c
>> b/gdb/testsuite/gdb.arch/altivec-regs.c
>> index 4d4fe3f5dbb..8f3b729fe3f 100644
>> --- a/gdb/testsuite/gdb.arch/altivec-regs.c
>> +++ b/gdb/testsuite/gdb.arch/altivec-regs.c
>> @@ -2,7 +2,7 @@
>>   #include <stdio.h>
>>
>>   vector unsigned int
>> -vector_fun (vector unsigned int a, vector unsigned int b)
>> +vector_fun (volatile vector unsigned int a, volatile vector unsigned
>> int b)
>>   {
>>     vector unsigned int c;
>>     a = ((vector unsigned int) vec_splat_u8(2));
>>
>> base-commit: 2650ea9730e31fc5c9111afc1a689dbca76707f5
> 
> I ran this test case before and after your commit on my Power 10 and my
> Power 9 box.  I did not see a failure before or after the commit on
> either machine.  The fix looks fine to me as it doesn't change the
> behavior on Power 9 or Power 10 that I can see.

Hi Carl,

thanks for confirming, good to know.

- Tom