On 20/09/2021 14:55, Qing Zhao wrote:
On Sep 20, 2021, at 8:18 AM, Richard Earnshaw <richard.earns...@foss.arm.com>
wrote:
On 20/09/2021 13:47, Qing Zhao wrote:
On Sep 20, 2021, at 5:43 AM, Richard Earnshaw <richard.earns...@foss.arm.com>
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 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
