> 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
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
