Re: [HELP Needed!][PATCH] testsuite: Fix gcc.target/aarch64/auto-init-* tests.

2021-09-21 Thread Qing Zhao via Gcc-patches
By using a newer version of dejagnu on aarch64,  the options in the testing 
cases are appended AFTER the options in the RUNTESTFLAGS.
As a result, my patch to the aarch64/auto-init-* tests passed without issue.

Thanks a lot for your help.

Qing

> On Sep 20, 2021, at 9:36 AM, Richard Earnshaw  
> wrote:
> 
> 
> 
> On 20/09/2021 14:55, Qing Zhao wrote:
>>> On Sep 20, 2021, at 8:18 AM, Richard Earnshaw 
>>>  wrote:
>>> 
>>> 
>>> 
>>> On 20/09/2021 13:47, Qing Zhao wrote:
> On Sep 20, 2021, at 5:43 AM, Richard Earnshaw 
>  wrote:
> 
> 
> 
> On 17/09/2021 20:48, Qing Zhao via Gcc-patches wrote:
>> Hi,
>> There are much less issues with aarch64/auto-init-* test cases.
>> Different -march values (from ‘armv8-a’, ‘armv8.1-a’, till ‘armv8.6-a’, 
>> ‘armv8-r’) do not change the pattern match.
>> Only
>> 1. -mabi=ilp32/lp64 impact two of the testing cases “auto-init-2.c” and 
>> “auto-init-padding-5.c”.
>> 2. -fstack-clash-protection impact two of the testing cases 
>> “auto-init-1.c” and “auto-init-7.c”.
>> Naturally the patch for this set is:
>> A. Adjust the patterns for ilp32 or lp64 in “auto-init-2.c” and 
>> “auto-init-padding-5.c”;
>> B. Add -fno-stack-protector to “auto-init-1.c” and “auto-init-7.c”
>> The above A fixed issue 1, however, the above B did not fix issue 2.
>> If I fixed “auto-init-1.c” as:
>> diff --git a/gcc/testsuite/gcc.target/aarch64/auto-init-1.c 
>> b/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
>> index 0fa4708..a38d91b 100644
>> --- a/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
>> +++ b/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
>> @@ -1,6 +1,6 @@
>>  /* Verify zero initialization for integer and pointer type automatic 
>> variables.  */
>>  /* { dg-do compile } */
>> -/* { dg-options "-ftrivial-auto-var-init=zero -fdump-rtl-expand" } */
>> +/* { dg-options "-ftrivial-auto-var-init=zero -fdump-rtl-expand 
>> -fno-stack-protector" } */
>>#ifndef __cplusplus
>>  # define bool _Bool
>> So, I took a look at the log file of the testing, and found that, If I 
>> tested it as:
>>  make check-gcc 
>> RUNTESTFLAGS='--target_board=unix\{-mabi=lp64/-fstack-clash-protection/-fstack-protector-all\}
>>  aarch64.exp=auto-init*’
>> In the log file, I got:
>> /home/qinzhao/Work/GCC/build_git/gcc/xgcc 
>> -B/home/qinzhao/Work/GCC/build_git/gcc/ 
>> /home/qinzhao/Work/GCC/latest_gcc_git/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
>>   -fdiagnostics-plain-output  -ftrivial-auto-var-init=zero 
>> -fdump-rtl-expand -fno-stack-protector -ffat-lto-objects -S  -mabi=lp64 
>> -fstack-clash-protection -fstack-protector-all  -o auto-init-1.s
>> From it, we can see, that the options that were passed through 
>> RUNTESTFLAGS “mabi-lp64 -fstack-clash-protection -fstack-protector-all” 
>> were appended AFTER the options inside the testing case through 
>> “dg-options”. As a result, the option “-fno-stack-protector” did not 
>> have any impact at all.
>> What’s the expected behavior for the order of these options? Should 
>> options through RUNTESTFLAGS be appended BEFORE or AFTER the options 
>> through testing cases?
>> For X86, the options through RUNTESTFLAGS are added BEFORE the options 
>> through testing cases. Therefore adding “-fno-stack-protector” has the 
>> expected result.
> 
> Can you check that you are using the same version of dejagnu on both 
> platforms?
 Stupid question:  how to check the version of it?
>>> 
>>> $ runtest --version
>> Thanks.
>> On aarch64:
>> qinzhao@gcc116:~/Work/GCC/build_git$ runtest --version
>> Expect version is5.45
>> Tcl version is   8.6
>> Framework version is 1.5
> 
> Ok, so this is dejagnu 1.5 (older versions of dejagnu reported the 'framework 
> version') ...
> 
>> On X86:
>> [opc@qinzhao-ol8u3-x86 gcc]$ runtest --version
>> WARNING: Couldn't find the global config file.
>> DejaGnu version  1.6.1
>> Expect version   5.45.4
>> Tcl version  8.6
> 
> While this is dejagnu 1.6.1
> 
> IIRC there were some changes to the way various options were combined at one 
> point and I suspect this may be the source of your problem.  Can you update 
> your dejagnu on your aarch64 system to be the same as that on x86?
> 
> R.
> 
>> So, is there anything wrong with the installation of runtest on X86?
>> Qing
>>> 
>>> R.
>>> 
 Qing
> 
> R.
> 
>> Is this a bug in aarch64 testing suite?
>> Thanks.
>> Qing



Re: [HELP Needed!][PATCH] testsuite: Fix gcc.target/aarch64/auto-init-* tests.

2021-09-20 Thread Qing Zhao via Gcc-patches


> On Sep 20, 2021, at 10:59 AM, Richard Earnshaw 
>  wrote:
> 
> 
> 
> On 20/09/2021 16:51, Qing Zhao via Gcc-patches wrote:
>>> On Sep 20, 2021, at 9:36 AM, Richard Earnshaw 
>>>  wrote:
>>> 
>>> 
>>> 
>>> On 20/09/2021 14:55, Qing Zhao wrote:
> On Sep 20, 2021, at 8:18 AM, Richard Earnshaw 
>  wrote:
> 
> 
> 
> On 20/09/2021 13:47, Qing Zhao wrote:
>>> On Sep 20, 2021, at 5:43 AM, Richard Earnshaw 
>>>  wrote:
>>> 
>>> 
>>> 
>>> On 17/09/2021 20:48, Qing Zhao via Gcc-patches wrote:
 Hi,
 There are much less issues with aarch64/auto-init-* test cases.
 Different -march values (from ‘armv8-a’, ‘armv8.1-a’, till 
 ‘armv8.6-a’, ‘armv8-r’) do not change the pattern match.
 Only
 1. -mabi=ilp32/lp64 impact two of the testing cases “auto-init-2.c” 
 and “auto-init-padding-5.c”.
 2. -fstack-clash-protection impact two of the testing cases 
 “auto-init-1.c” and “auto-init-7.c”.
 Naturally the patch for this set is:
 A. Adjust the patterns for ilp32 or lp64 in “auto-init-2.c” and 
 “auto-init-padding-5.c”;
 B. Add -fno-stack-protector to “auto-init-1.c” and “auto-init-7.c”
 The above A fixed issue 1, however, the above B did not fix issue 2.
 If I fixed “auto-init-1.c” as:
 diff --git a/gcc/testsuite/gcc.target/aarch64/auto-init-1.c 
 b/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
 index 0fa4708..a38d91b 100644
 --- a/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
 +++ b/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
 @@ -1,6 +1,6 @@
  /* Verify zero initialization for integer and pointer type automatic 
 variables.  */
  /* { dg-do compile } */
 -/* { dg-options "-ftrivial-auto-var-init=zero -fdump-rtl-expand" } */
 +/* { dg-options "-ftrivial-auto-var-init=zero -fdump-rtl-expand 
 -fno-stack-protector" } */
#ifndef __cplusplus
  # define bool _Bool
 So, I took a look at the log file of the testing, and found that, If I 
 tested it as:
  make check-gcc 
 RUNTESTFLAGS='--target_board=unix\{-mabi=lp64/-fstack-clash-protection/-fstack-protector-all\}
  aarch64.exp=auto-init*’
 In the log file, I got:
 /home/qinzhao/Work/GCC/build_git/gcc/xgcc 
 -B/home/qinzhao/Work/GCC/build_git/gcc/ 
 /home/qinzhao/Work/GCC/latest_gcc_git/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
   -fdiagnostics-plain-output  -ftrivial-auto-var-init=zero 
 -fdump-rtl-expand -fno-stack-protector -ffat-lto-objects -S  
 -mabi=lp64 -fstack-clash-protection -fstack-protector-all  -o 
 auto-init-1.s
 From it, we can see, that the options that were passed through 
 RUNTESTFLAGS “mabi-lp64 -fstack-clash-protection 
 -fstack-protector-all” were appended AFTER the options inside the 
 testing case through “dg-options”. As a result, the option 
 “-fno-stack-protector” did not have any impact at all.
 What’s the expected behavior for the order of these options? Should 
 options through RUNTESTFLAGS be appended BEFORE or AFTER the options 
 through testing cases?
 For X86, the options through RUNTESTFLAGS are added BEFORE the options 
 through testing cases. Therefore adding “-fno-stack-protector” has the 
 expected result.
>>> 
>>> Can you check that you are using the same version of dejagnu on both 
>>> platforms?
>> Stupid question:  how to check the version of it?
> 
> $ runtest --version
 Thanks.
 On aarch64:
 qinzhao@gcc116:~/Work/GCC/build_git$ runtest --version
 Expect version is  5.45
 Tcl version is 8.6
 Framework version is   1.5
>>> 
>>> Ok, so this is dejagnu 1.5 (older versions of dejagnu reported the 
>>> 'framework version') ...
>>> 
 On X86:
 [opc@qinzhao-ol8u3-x86 gcc]$ runtest --version
 WARNING: Couldn't find the global config file.
 DejaGnu version1.6.1
 Expect version 5.45.4
 Tcl version8.6
>>> 
>>> While this is dejagnu 1.6.1
>>> 
>>> IIRC there were some changes to the way various options were combined at 
>>> one point and I suspect this may be the source of your problem.  Can you 
>>> update your dejagnu on your aarch64 system to be the same as that on x86?
>> The aarch64 machine I used is a GCC farm machine, looks like it has an older 
>> version of dejagnu. I don’t have permission to update it myself.
>> I will use another aarch64 machine to test this to see whether a higher 
>> version of dejagnu can resolve the issue or not.
> 
> You could probably try installing a local copy of dejagnu in, for example, 
> ~/tools and then adding that to your path before the system version.
Will try this too.
thanks.

Qing
> 
> R.
> 
>> Thanks a lot for your help.
>> 

Re: [HELP Needed!][PATCH] testsuite: Fix gcc.target/aarch64/auto-init-* tests.

2021-09-20 Thread Richard Earnshaw via Gcc-patches




On 20/09/2021 16:51, Qing Zhao via Gcc-patches wrote:




On Sep 20, 2021, at 9:36 AM, Richard Earnshaw  
wrote:



On 20/09/2021 14:55, Qing Zhao wrote:

On Sep 20, 2021, at 8:18 AM, Richard Earnshaw  
wrote:



On 20/09/2021 13:47, Qing Zhao wrote:

On Sep 20, 2021, at 5:43 AM, Richard Earnshaw  
wrote:



On 17/09/2021 20:48, Qing Zhao via Gcc-patches wrote:

Hi,
There are much less issues with aarch64/auto-init-* test cases.
Different -march values (from ‘armv8-a’, ‘armv8.1-a’, till ‘armv8.6-a’, 
‘armv8-r’) do not change the pattern match.
Only
1. -mabi=ilp32/lp64 impact two of the testing cases “auto-init-2.c” and 
“auto-init-padding-5.c”.
2. -fstack-clash-protection impact two of the testing cases “auto-init-1.c” and 
“auto-init-7.c”.
Naturally the patch for this set is:
A. Adjust the patterns for ilp32 or lp64 in “auto-init-2.c” and 
“auto-init-padding-5.c”;
B. Add -fno-stack-protector to “auto-init-1.c” and “auto-init-7.c”
The above A fixed issue 1, however, the above B did not fix issue 2.
If I fixed “auto-init-1.c” as:
diff --git a/gcc/testsuite/gcc.target/aarch64/auto-init-1.c 
b/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
index 0fa4708..a38d91b 100644
--- a/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
+++ b/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
@@ -1,6 +1,6 @@
  /* Verify zero initialization for integer and pointer type automatic 
variables.  */
  /* { dg-do compile } */
-/* { dg-options "-ftrivial-auto-var-init=zero -fdump-rtl-expand" } */
+/* { dg-options "-ftrivial-auto-var-init=zero -fdump-rtl-expand 
-fno-stack-protector" } */
#ifndef __cplusplus
  # define bool _Bool
So, I took a look at the log file of the testing, and found that, If I tested 
it as:
  make check-gcc 
RUNTESTFLAGS='--target_board=unix\{-mabi=lp64/-fstack-clash-protection/-fstack-protector-all\}
 aarch64.exp=auto-init*’
In the log file, I got:
/home/qinzhao/Work/GCC/build_git/gcc/xgcc 
-B/home/qinzhao/Work/GCC/build_git/gcc/ 
/home/qinzhao/Work/GCC/latest_gcc_git/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
  -fdiagnostics-plain-output  -ftrivial-auto-var-init=zero -fdump-rtl-expand 
-fno-stack-protector -ffat-lto-objects -S  -mabi=lp64 -fstack-clash-protection 
-fstack-protector-all  -o auto-init-1.s
 From it, we can see, that the options that were passed through RUNTESTFLAGS 
“mabi-lp64 -fstack-clash-protection -fstack-protector-all” were appended AFTER 
the options inside the testing case through “dg-options”. As a result, the 
option “-fno-stack-protector” did not have any impact at all.
What’s the expected behavior for the order of these options? Should options 
through RUNTESTFLAGS be appended BEFORE or AFTER the options through testing 
cases?
For X86, the options through RUNTESTFLAGS are added BEFORE the options through 
testing cases. Therefore adding “-fno-stack-protector” has the expected result.


Can you check that you are using the same version of dejagnu on both platforms?

Stupid question:  how to check the version of it?


$ runtest --version

Thanks.
On aarch64:
qinzhao@gcc116:~/Work/GCC/build_git$ runtest --version
Expect version is   5.45
Tcl version is  8.6
Framework version is1.5


Ok, so this is dejagnu 1.5 (older versions of dejagnu reported the 'framework 
version') ...


On X86:
[opc@qinzhao-ol8u3-x86 gcc]$ runtest --version
WARNING: Couldn't find the global config file.
DejaGnu version 1.6.1
Expect version  5.45.4
Tcl version 8.6


While this is dejagnu 1.6.1

IIRC there were some changes to the way various options were combined at one 
point and I suspect this may be the source of your problem.  Can you update 
your dejagnu on your aarch64 system to be the same as that on x86?


The aarch64 machine I used is a GCC farm machine, looks like it has an older 
version of dejagnu. I don’t have permission to update it myself.

I will use another aarch64 machine to test this to see whether a higher version 
of dejagnu can resolve the issue or not.


You could probably try installing a local copy of dejagnu in, for 
example, ~/tools and then adding that to your path before the system 
version.


R.



Thanks a lot for your help.

Qing


R.


So, is there anything wrong with the installation of runtest on X86?
Qing


R.


Qing


R.


Is this a bug in aarch64 testing suite?
Thanks.
Qing




Re: [HELP Needed!][PATCH] testsuite: Fix gcc.target/aarch64/auto-init-* tests.

2021-09-20 Thread Qing Zhao via Gcc-patches


> On Sep 20, 2021, at 9:36 AM, Richard Earnshaw  
> wrote:
> 
> 
> 
> On 20/09/2021 14:55, Qing Zhao wrote:
>>> On Sep 20, 2021, at 8:18 AM, Richard Earnshaw 
>>>  wrote:
>>> 
>>> 
>>> 
>>> On 20/09/2021 13:47, Qing Zhao wrote:
> On Sep 20, 2021, at 5:43 AM, Richard Earnshaw 
>  wrote:
> 
> 
> 
> On 17/09/2021 20:48, Qing Zhao via Gcc-patches wrote:
>> Hi,
>> There are much less issues with aarch64/auto-init-* test cases.
>> Different -march values (from ‘armv8-a’, ‘armv8.1-a’, till ‘armv8.6-a’, 
>> ‘armv8-r’) do not change the pattern match.
>> Only
>> 1. -mabi=ilp32/lp64 impact two of the testing cases “auto-init-2.c” and 
>> “auto-init-padding-5.c”.
>> 2. -fstack-clash-protection impact two of the testing cases 
>> “auto-init-1.c” and “auto-init-7.c”.
>> Naturally the patch for this set is:
>> A. Adjust the patterns for ilp32 or lp64 in “auto-init-2.c” and 
>> “auto-init-padding-5.c”;
>> B. Add -fno-stack-protector to “auto-init-1.c” and “auto-init-7.c”
>> The above A fixed issue 1, however, the above B did not fix issue 2.
>> If I fixed “auto-init-1.c” as:
>> diff --git a/gcc/testsuite/gcc.target/aarch64/auto-init-1.c 
>> b/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
>> index 0fa4708..a38d91b 100644
>> --- a/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
>> +++ b/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
>> @@ -1,6 +1,6 @@
>>  /* Verify zero initialization for integer and pointer type automatic 
>> variables.  */
>>  /* { dg-do compile } */
>> -/* { dg-options "-ftrivial-auto-var-init=zero -fdump-rtl-expand" } */
>> +/* { dg-options "-ftrivial-auto-var-init=zero -fdump-rtl-expand 
>> -fno-stack-protector" } */
>>#ifndef __cplusplus
>>  # define bool _Bool
>> So, I took a look at the log file of the testing, and found that, If I 
>> tested it as:
>>  make check-gcc 
>> RUNTESTFLAGS='--target_board=unix\{-mabi=lp64/-fstack-clash-protection/-fstack-protector-all\}
>>  aarch64.exp=auto-init*’
>> In the log file, I got:
>> /home/qinzhao/Work/GCC/build_git/gcc/xgcc 
>> -B/home/qinzhao/Work/GCC/build_git/gcc/ 
>> /home/qinzhao/Work/GCC/latest_gcc_git/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
>>   -fdiagnostics-plain-output  -ftrivial-auto-var-init=zero 
>> -fdump-rtl-expand -fno-stack-protector -ffat-lto-objects -S  -mabi=lp64 
>> -fstack-clash-protection -fstack-protector-all  -o auto-init-1.s
>> From it, we can see, that the options that were passed through 
>> RUNTESTFLAGS “mabi-lp64 -fstack-clash-protection -fstack-protector-all” 
>> were appended AFTER the options inside the testing case through 
>> “dg-options”. As a result, the option “-fno-stack-protector” did not 
>> have any impact at all.
>> What’s the expected behavior for the order of these options? Should 
>> options through RUNTESTFLAGS be appended BEFORE or AFTER the options 
>> through testing cases?
>> For X86, the options through RUNTESTFLAGS are added BEFORE the options 
>> through testing cases. Therefore adding “-fno-stack-protector” has the 
>> expected result.
> 
> Can you check that you are using the same version of dejagnu on both 
> platforms?
 Stupid question:  how to check the version of it?
>>> 
>>> $ runtest --version
>> Thanks.
>> On aarch64:
>> qinzhao@gcc116:~/Work/GCC/build_git$ runtest --version
>> Expect version is5.45
>> Tcl version is   8.6
>> Framework version is 1.5
> 
> Ok, so this is dejagnu 1.5 (older versions of dejagnu reported the 'framework 
> version') ...
> 
>> On X86:
>> [opc@qinzhao-ol8u3-x86 gcc]$ runtest --version
>> WARNING: Couldn't find the global config file.
>> DejaGnu version  1.6.1
>> Expect version   5.45.4
>> Tcl version  8.6
> 
> While this is dejagnu 1.6.1
> 
> IIRC there were some changes to the way various options were combined at one 
> point and I suspect this may be the source of your problem.  Can you update 
> your dejagnu on your aarch64 system to be the same as that on x86?

The aarch64 machine I used is a GCC farm machine, looks like it has an older 
version of dejagnu. I don’t have permission to update it myself.

I will use another aarch64 machine to test this to see whether a higher version 
of dejagnu can resolve the issue or not.

Thanks a lot for your help.

Qing
> 
> R.
> 
>> So, is there anything wrong with the installation of runtest on X86?
>> Qing
>>> 
>>> R.
>>> 
 Qing
> 
> R.
> 
>> Is this a bug in aarch64 testing suite?
>> Thanks.
>> Qing



Re: [HELP Needed!][PATCH] testsuite: Fix gcc.target/aarch64/auto-init-* tests.

2021-09-20 Thread Richard Earnshaw via Gcc-patches




On 20/09/2021 14:55, Qing Zhao wrote:




On Sep 20, 2021, at 8:18 AM, Richard Earnshaw  
wrote:



On 20/09/2021 13:47, Qing Zhao wrote:

On Sep 20, 2021, at 5:43 AM, Richard Earnshaw  
wrote:



On 17/09/2021 20:48, Qing Zhao via Gcc-patches wrote:

Hi,
There are much less issues with aarch64/auto-init-* test cases.
Different -march values (from ‘armv8-a’, ‘armv8.1-a’, till ‘armv8.6-a’, 
‘armv8-r’) do not change the pattern match.
Only
1. -mabi=ilp32/lp64 impact two of the testing cases “auto-init-2.c” and 
“auto-init-padding-5.c”.
2. -fstack-clash-protection impact two of the testing cases “auto-init-1.c” and 
“auto-init-7.c”.
Naturally the patch for this set is:
A. Adjust the patterns for ilp32 or lp64 in “auto-init-2.c” and 
“auto-init-padding-5.c”;
B. Add -fno-stack-protector to “auto-init-1.c” and “auto-init-7.c”
The above A fixed issue 1, however, the above B did not fix issue 2.
If I fixed “auto-init-1.c” as:
diff --git a/gcc/testsuite/gcc.target/aarch64/auto-init-1.c 
b/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
index 0fa4708..a38d91b 100644
--- a/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
+++ b/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
@@ -1,6 +1,6 @@
  /* Verify zero initialization for integer and pointer type automatic 
variables.  */
  /* { dg-do compile } */
-/* { dg-options "-ftrivial-auto-var-init=zero -fdump-rtl-expand" } */
+/* { dg-options "-ftrivial-auto-var-init=zero -fdump-rtl-expand 
-fno-stack-protector" } */
#ifndef __cplusplus
  # define bool _Bool
So, I took a look at the log file of the testing, and found that, If I tested 
it as:
  make check-gcc 
RUNTESTFLAGS='--target_board=unix\{-mabi=lp64/-fstack-clash-protection/-fstack-protector-all\}
 aarch64.exp=auto-init*’
In the log file, I got:
/home/qinzhao/Work/GCC/build_git/gcc/xgcc 
-B/home/qinzhao/Work/GCC/build_git/gcc/ 
/home/qinzhao/Work/GCC/latest_gcc_git/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
  -fdiagnostics-plain-output  -ftrivial-auto-var-init=zero -fdump-rtl-expand 
-fno-stack-protector -ffat-lto-objects -S  -mabi=lp64 -fstack-clash-protection 
-fstack-protector-all  -o auto-init-1.s
 From it, we can see, that the options that were passed through RUNTESTFLAGS 
“mabi-lp64 -fstack-clash-protection -fstack-protector-all” were appended AFTER 
the options inside the testing case through “dg-options”. As a result, the 
option “-fno-stack-protector” did not have any impact at all.
What’s the expected behavior for the order of these options? Should options 
through RUNTESTFLAGS be appended BEFORE or AFTER the options through testing 
cases?
For X86, the options through RUNTESTFLAGS are added BEFORE the options through 
testing cases. Therefore adding “-fno-stack-protector” has the expected result.


Can you check that you are using the same version of dejagnu on both platforms?

Stupid question:  how to check the version of it?


$ runtest --version


Thanks.

On aarch64:
qinzhao@gcc116:~/Work/GCC/build_git$ runtest --version
Expect version is   5.45
Tcl version is  8.6
Framework version is1.5


Ok, so this is dejagnu 1.5 (older versions of dejagnu reported the 
'framework version') ...




On X86:
[opc@qinzhao-ol8u3-x86 gcc]$ runtest --version
WARNING: Couldn't find the global config file.
DejaGnu version 1.6.1
Expect version  5.45.4
Tcl version 8.6


While this is dejagnu 1.6.1

IIRC there were some changes to the way various options were combined at 
one point and I suspect this may be the source of your problem.  Can you 
update your dejagnu on your aarch64 system to be the same as that on x86?


R.



So, is there anything wrong with the installation of runtest on X86?

Qing




R.


Qing


R.


Is this a bug in aarch64 testing suite?
Thanks.
Qing




Re: [HELP Needed!][PATCH] testsuite: Fix gcc.target/aarch64/auto-init-* tests.

2021-09-20 Thread Qing Zhao via Gcc-patches


> On Sep 20, 2021, at 8:18 AM, Richard Earnshaw  
> wrote:
> 
> 
> 
> On 20/09/2021 13:47, Qing Zhao wrote:
>>> On Sep 20, 2021, at 5:43 AM, Richard Earnshaw 
>>>  wrote:
>>> 
>>> 
>>> 
>>> On 17/09/2021 20:48, Qing Zhao via Gcc-patches wrote:
 Hi,
 There are much less issues with aarch64/auto-init-* test cases.
 Different -march values (from ‘armv8-a’, ‘armv8.1-a’, till ‘armv8.6-a’, 
 ‘armv8-r’) do not change the pattern match.
 Only
 1. -mabi=ilp32/lp64 impact two of the testing cases “auto-init-2.c” and 
 “auto-init-padding-5.c”.
 2. -fstack-clash-protection impact two of the testing cases 
 “auto-init-1.c” and “auto-init-7.c”.
 Naturally the patch for this set is:
 A. Adjust the patterns for ilp32 or lp64 in “auto-init-2.c” and 
 “auto-init-padding-5.c”;
 B. Add -fno-stack-protector to “auto-init-1.c” and “auto-init-7.c”
 The above A fixed issue 1, however, the above B did not fix issue 2.
 If I fixed “auto-init-1.c” as:
 diff --git a/gcc/testsuite/gcc.target/aarch64/auto-init-1.c 
 b/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
 index 0fa4708..a38d91b 100644
 --- a/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
 +++ b/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
 @@ -1,6 +1,6 @@
  /* Verify zero initialization for integer and pointer type automatic 
 variables.  */
  /* { dg-do compile } */
 -/* { dg-options "-ftrivial-auto-var-init=zero -fdump-rtl-expand" } */
 +/* { dg-options "-ftrivial-auto-var-init=zero -fdump-rtl-expand 
 -fno-stack-protector" } */
#ifndef __cplusplus
  # define bool _Bool
 So, I took a look at the log file of the testing, and found that, If I 
 tested it as:
  make check-gcc 
 RUNTESTFLAGS='--target_board=unix\{-mabi=lp64/-fstack-clash-protection/-fstack-protector-all\}
  aarch64.exp=auto-init*’
 In the log file, I got:
 /home/qinzhao/Work/GCC/build_git/gcc/xgcc 
 -B/home/qinzhao/Work/GCC/build_git/gcc/ 
 /home/qinzhao/Work/GCC/latest_gcc_git/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
   -fdiagnostics-plain-output  -ftrivial-auto-var-init=zero 
 -fdump-rtl-expand -fno-stack-protector -ffat-lto-objects -S  -mabi=lp64 
 -fstack-clash-protection -fstack-protector-all  -o auto-init-1.s
 From it, we can see, that the options that were passed through 
 RUNTESTFLAGS “mabi-lp64 -fstack-clash-protection -fstack-protector-all” 
 were appended AFTER the options inside the testing case through 
 “dg-options”. As a result, the option “-fno-stack-protector” did not have 
 any impact at all.
 What’s the expected behavior for the order of these options? Should 
 options through RUNTESTFLAGS be appended BEFORE or AFTER the options 
 through testing cases?
 For X86, the options through RUNTESTFLAGS are added BEFORE the options 
 through testing cases. Therefore adding “-fno-stack-protector” has the 
 expected result.
>>> 
>>> Can you check that you are using the same version of dejagnu on both 
>>> platforms?
>> Stupid question:  how to check the version of it?
> 
> $ runtest --version

Thanks.

On aarch64:
qinzhao@gcc116:~/Work/GCC/build_git$ runtest --version
Expect version is   5.45
Tcl version is  8.6
Framework version is1.5

On X86:
[opc@qinzhao-ol8u3-x86 gcc]$ runtest --version
WARNING: Couldn't find the global config file.
DejaGnu version 1.6.1
Expect version  5.45.4
Tcl version 8.6

So, is there anything wrong with the installation of runtest on X86?

Qing


> 
> R.
> 
>> Qing
>>> 
>>> R.
>>> 
 Is this a bug in aarch64 testing suite?
 Thanks.
 Qing



Re: [HELP Needed!][PATCH] testsuite: Fix gcc.target/aarch64/auto-init-* tests.

2021-09-20 Thread Richard Earnshaw via Gcc-patches




On 20/09/2021 13:47, Qing Zhao wrote:




On Sep 20, 2021, at 5:43 AM, Richard Earnshaw  
wrote:



On 17/09/2021 20:48, Qing Zhao via Gcc-patches wrote:

Hi,
There are much less issues with aarch64/auto-init-* test cases.
Different -march values (from ‘armv8-a’, ‘armv8.1-a’, till ‘armv8.6-a’, 
‘armv8-r’) do not change the pattern match.
Only
1. -mabi=ilp32/lp64 impact two of the testing cases “auto-init-2.c” and 
“auto-init-padding-5.c”.
2. -fstack-clash-protection impact two of the testing cases “auto-init-1.c” and 
“auto-init-7.c”.
Naturally the patch for this set is:
A. Adjust the patterns for ilp32 or lp64 in “auto-init-2.c” and 
“auto-init-padding-5.c”;
B. Add -fno-stack-protector to “auto-init-1.c” and “auto-init-7.c”
The above A fixed issue 1, however, the above B did not fix issue 2.
If I fixed “auto-init-1.c” as:
diff --git a/gcc/testsuite/gcc.target/aarch64/auto-init-1.c 
b/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
index 0fa4708..a38d91b 100644
--- a/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
+++ b/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
@@ -1,6 +1,6 @@
  /* Verify zero initialization for integer and pointer type automatic 
variables.  */
  /* { dg-do compile } */
-/* { dg-options "-ftrivial-auto-var-init=zero -fdump-rtl-expand" } */
+/* { dg-options "-ftrivial-auto-var-init=zero -fdump-rtl-expand 
-fno-stack-protector" } */
#ifndef __cplusplus
  # define bool _Bool
So, I took a look at the log file of the testing, and found that, If I tested 
it as:
  make check-gcc 
RUNTESTFLAGS='--target_board=unix\{-mabi=lp64/-fstack-clash-protection/-fstack-protector-all\}
 aarch64.exp=auto-init*’
In the log file, I got:
/home/qinzhao/Work/GCC/build_git/gcc/xgcc 
-B/home/qinzhao/Work/GCC/build_git/gcc/ 
/home/qinzhao/Work/GCC/latest_gcc_git/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
  -fdiagnostics-plain-output  -ftrivial-auto-var-init=zero -fdump-rtl-expand 
-fno-stack-protector -ffat-lto-objects -S  -mabi=lp64 -fstack-clash-protection 
-fstack-protector-all  -o auto-init-1.s
 From it, we can see, that the options that were passed through RUNTESTFLAGS 
“mabi-lp64 -fstack-clash-protection -fstack-protector-all” were appended AFTER 
the options inside the testing case through “dg-options”. As a result, the 
option “-fno-stack-protector” did not have any impact at all.
What’s the expected behavior for the order of these options? Should options 
through RUNTESTFLAGS be appended BEFORE or AFTER the options through testing 
cases?
For X86, the options through RUNTESTFLAGS are added BEFORE the options through 
testing cases. Therefore adding “-fno-stack-protector” has the expected result.


Can you check that you are using the same version of dejagnu on both platforms?


Stupid question:  how to check the version of it?



$ runtest --version

R.


Qing


R.


Is this a bug in aarch64 testing suite?
Thanks.
Qing




Re: [HELP Needed!][PATCH] testsuite: Fix gcc.target/aarch64/auto-init-* tests.

2021-09-20 Thread Qing Zhao via Gcc-patches


> On Sep 20, 2021, at 5:43 AM, Richard Earnshaw  
> wrote:
> 
> 
> 
> On 17/09/2021 20:48, Qing Zhao via Gcc-patches wrote:
>> Hi,
>> There are much less issues with aarch64/auto-init-* test cases.
>> Different -march values (from ‘armv8-a’, ‘armv8.1-a’, till ‘armv8.6-a’, 
>> ‘armv8-r’) do not change the pattern match.
>> Only
>> 1. -mabi=ilp32/lp64 impact two of the testing cases “auto-init-2.c” and 
>> “auto-init-padding-5.c”.
>> 2. -fstack-clash-protection impact two of the testing cases “auto-init-1.c” 
>> and “auto-init-7.c”.
>> Naturally the patch for this set is:
>> A. Adjust the patterns for ilp32 or lp64 in “auto-init-2.c” and 
>> “auto-init-padding-5.c”;
>> B. Add -fno-stack-protector to “auto-init-1.c” and “auto-init-7.c”
>> The above A fixed issue 1, however, the above B did not fix issue 2.
>> If I fixed “auto-init-1.c” as:
>> diff --git a/gcc/testsuite/gcc.target/aarch64/auto-init-1.c 
>> b/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
>> index 0fa4708..a38d91b 100644
>> --- a/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
>> +++ b/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
>> @@ -1,6 +1,6 @@
>>  /* Verify zero initialization for integer and pointer type automatic 
>> variables.  */
>>  /* { dg-do compile } */
>> -/* { dg-options "-ftrivial-auto-var-init=zero -fdump-rtl-expand" } */
>> +/* { dg-options "-ftrivial-auto-var-init=zero -fdump-rtl-expand 
>> -fno-stack-protector" } */
>>#ifndef __cplusplus
>>  # define bool _Bool
>> So, I took a look at the log file of the testing, and found that, If I 
>> tested it as:
>>  make check-gcc 
>> RUNTESTFLAGS='--target_board=unix\{-mabi=lp64/-fstack-clash-protection/-fstack-protector-all\}
>>  aarch64.exp=auto-init*’
>> In the log file, I got:
>> /home/qinzhao/Work/GCC/build_git/gcc/xgcc 
>> -B/home/qinzhao/Work/GCC/build_git/gcc/ 
>> /home/qinzhao/Work/GCC/latest_gcc_git/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
>>   -fdiagnostics-plain-output  -ftrivial-auto-var-init=zero -fdump-rtl-expand 
>> -fno-stack-protector -ffat-lto-objects -S  -mabi=lp64 
>> -fstack-clash-protection -fstack-protector-all  -o auto-init-1.s
>> From it, we can see, that the options that were passed through RUNTESTFLAGS 
>> “mabi-lp64 -fstack-clash-protection -fstack-protector-all” were appended 
>> AFTER the options inside the testing case through “dg-options”. As a result, 
>> the option “-fno-stack-protector” did not have any impact at all.
>> What’s the expected behavior for the order of these options? Should options 
>> through RUNTESTFLAGS be appended BEFORE or AFTER the options through testing 
>> cases?
>> For X86, the options through RUNTESTFLAGS are added BEFORE the options 
>> through testing cases. Therefore adding “-fno-stack-protector” has the 
>> expected result.
> 
> Can you check that you are using the same version of dejagnu on both 
> platforms?

Stupid question:  how to check the version of it?

Qing
> 
> R.
> 
>> Is this a bug in aarch64 testing suite?
>> Thanks.
>> Qing



Re: [HELP Needed!][PATCH] testsuite: Fix gcc.target/aarch64/auto-init-* tests.

2021-09-20 Thread Richard Earnshaw via Gcc-patches




On 17/09/2021 20:48, Qing Zhao via Gcc-patches wrote:

Hi,

There are much less issues with aarch64/auto-init-* test cases.
Different -march values (from ‘armv8-a’, ‘armv8.1-a’, till ‘armv8.6-a’, 
‘armv8-r’) do not change the pattern match.

Only

1. -mabi=ilp32/lp64 impact two of the testing cases “auto-init-2.c” and 
“auto-init-padding-5.c”.
2. -fstack-clash-protection impact two of the testing cases “auto-init-1.c” and 
“auto-init-7.c”.

Naturally the patch for this set is:

A. Adjust the patterns for ilp32 or lp64 in “auto-init-2.c” and 
“auto-init-padding-5.c”;
B. Add -fno-stack-protector to “auto-init-1.c” and “auto-init-7.c”


The above A fixed issue 1, however, the above B did not fix issue 2.

If I fixed “auto-init-1.c” as:

diff --git a/gcc/testsuite/gcc.target/aarch64/auto-init-1.c 
b/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
index 0fa4708..a38d91b 100644
--- a/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
+++ b/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
@@ -1,6 +1,6 @@
  /* Verify zero initialization for integer and pointer type automatic 
variables.  */
  /* { dg-do compile } */
-/* { dg-options "-ftrivial-auto-var-init=zero -fdump-rtl-expand" } */
+/* { dg-options "-ftrivial-auto-var-init=zero -fdump-rtl-expand 
-fno-stack-protector" } */
  
  #ifndef __cplusplus

  # define bool _Bool

So, I took a look at the log file of the testing, and found that, If I tested 
it as:

  make check-gcc 
RUNTESTFLAGS='--target_board=unix\{-mabi=lp64/-fstack-clash-protection/-fstack-protector-all\}
 aarch64.exp=auto-init*’

In the log file, I got:

/home/qinzhao/Work/GCC/build_git/gcc/xgcc 
-B/home/qinzhao/Work/GCC/build_git/gcc/ 
/home/qinzhao/Work/GCC/latest_gcc_git/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
  -fdiagnostics-plain-output  -ftrivial-auto-var-init=zero -fdump-rtl-expand 
-fno-stack-protector -ffat-lto-objects -S  -mabi=lp64 -fstack-clash-protection 
-fstack-protector-all  -o auto-init-1.s

 From it, we can see, that the options that were passed through RUNTESTFLAGS 
“mabi-lp64 -fstack-clash-protection -fstack-protector-all” were appended AFTER 
the options inside the testing case through “dg-options”. As a result, the 
option “-fno-stack-protector” did not have any impact at all.

What’s the expected behavior for the order of these options? Should options 
through RUNTESTFLAGS be appended BEFORE or AFTER the options through testing 
cases?

For X86, the options through RUNTESTFLAGS are added BEFORE the options through 
testing cases. Therefore adding “-fno-stack-protector” has the expected result.



Can you check that you are using the same version of dejagnu on both 
platforms?


R.


Is this a bug in aarch64 testing suite?

Thanks.

Qing




[HELP Needed!][PATCH] testsuite: Fix gcc.target/aarch64/auto-init-* tests.

2021-09-17 Thread Qing Zhao via Gcc-patches
Hi,

There are much less issues with aarch64/auto-init-* test cases.
Different -march values (from ‘armv8-a’, ‘armv8.1-a’, till ‘armv8.6-a’, 
‘armv8-r’) do not change the pattern match.

Only 

1. -mabi=ilp32/lp64 impact two of the testing cases “auto-init-2.c” and 
“auto-init-padding-5.c”.
2. -fstack-clash-protection impact two of the testing cases “auto-init-1.c” and 
“auto-init-7.c”.

Naturally the patch for this set is:

A. Adjust the patterns for ilp32 or lp64 in “auto-init-2.c” and 
“auto-init-padding-5.c”;
B. Add -fno-stack-protector to “auto-init-1.c” and “auto-init-7.c”


The above A fixed issue 1, however, the above B did not fix issue 2. 

If I fixed “auto-init-1.c” as:

diff --git a/gcc/testsuite/gcc.target/aarch64/auto-init-1.c 
b/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
index 0fa4708..a38d91b 100644
--- a/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
+++ b/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
@@ -1,6 +1,6 @@
 /* Verify zero initialization for integer and pointer type automatic 
variables.  */
 /* { dg-do compile } */
-/* { dg-options "-ftrivial-auto-var-init=zero -fdump-rtl-expand" } */
+/* { dg-options "-ftrivial-auto-var-init=zero -fdump-rtl-expand 
-fno-stack-protector" } */
 
 #ifndef __cplusplus
 # define bool _Bool

So, I took a look at the log file of the testing, and found that, If I tested 
it as:

 make check-gcc 
RUNTESTFLAGS='--target_board=unix\{-mabi=lp64/-fstack-clash-protection/-fstack-protector-all\}
 aarch64.exp=auto-init*’

In the log file, I got:

/home/qinzhao/Work/GCC/build_git/gcc/xgcc 
-B/home/qinzhao/Work/GCC/build_git/gcc/ 
/home/qinzhao/Work/GCC/latest_gcc_git/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
  -fdiagnostics-plain-output  -ftrivial-auto-var-init=zero -fdump-rtl-expand 
-fno-stack-protector -ffat-lto-objects -S  -mabi=lp64 -fstack-clash-protection 
-fstack-protector-all  -o auto-init-1.s

From it, we can see, that the options that were passed through RUNTESTFLAGS 
“mabi-lp64 -fstack-clash-protection -fstack-protector-all” were appended AFTER 
the options inside the testing case through “dg-options”. As a result, the 
option “-fno-stack-protector” did not have any impact at all.

What’s the expected behavior for the order of these options? Should options 
through RUNTESTFLAGS be appended BEFORE or AFTER the options through testing 
cases?

For X86, the options through RUNTESTFLAGS are added BEFORE the options through 
testing cases. Therefore adding “-fno-stack-protector” has the expected result.

Is this a bug in aarch64 testing suite?

Thanks.

Qing