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 <richard.earns...@foss.arm.com>
> wrote:
>
>
>
> 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
