> 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?
Qing
>
> R.
>
>> Is this a bug in aarch64 testing suite?
>> Thanks.
>> Qing
