> On Sep 20, 2021, at 10:59 AM, Richard Earnshaw
> <richard.earns...@foss.arm.com> wrote:
>
>
>
> On 20/09/2021 16:51, Qing Zhao via Gcc-patches wrote:
>>> 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?
>> 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.
>> 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
