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