Message ID | EF0EEFDB-D63F-4F75-8781-7E7DA400480E@oracle.com |
---|---|
State | New |
Headers | show |
Series | [HELP,Needed!] testsuite: Fix gcc.target/aarch64/auto-init-* tests. | expand |
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? R. > Is this a bug in aarch64 testing suite? > > Thanks. > > Qing > >
> On Sep 20, 2021, at 5:43 AM, Richard Earnshaw <Richard.Earnshaw@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
On 20/09/2021 13:47, Qing Zhao wrote: > > >> On Sep 20, 2021, at 5:43 AM, Richard Earnshaw <Richard.Earnshaw@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 R. > Qing >> >> R. >> >>> Is this a bug in aarch64 testing suite? >>> Thanks. >>> Qing >
> On Sep 20, 2021, at 8:18 AM, Richard Earnshaw <Richard.Earnshaw@foss.arm.com> wrote: > > > > On 20/09/2021 13:47, Qing Zhao wrote: >>> On Sep 20, 2021, at 5:43 AM, Richard Earnshaw <Richard.Earnshaw@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
On 20/09/2021 14:55, Qing Zhao wrote: > > >> On Sep 20, 2021, at 8:18 AM, Richard Earnshaw <Richard.Earnshaw@foss.arm.com> wrote: >> >> >> >> On 20/09/2021 13:47, Qing Zhao wrote: >>>> On Sep 20, 2021, at 5:43 AM, Richard Earnshaw <Richard.Earnshaw@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 >
> On Sep 20, 2021, at 9:36 AM, Richard Earnshaw <Richard.Earnshaw@foss.arm.com> wrote: > > > > On 20/09/2021 14:55, Qing Zhao wrote: >>> On Sep 20, 2021, at 8:18 AM, Richard Earnshaw <Richard.Earnshaw@foss.arm.com> wrote: >>> >>> >>> >>> On 20/09/2021 13:47, Qing Zhao wrote: >>>>> On Sep 20, 2021, at 5:43 AM, Richard Earnshaw <Richard.Earnshaw@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. 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
On 20/09/2021 16:51, Qing Zhao via Gcc-patches wrote: > > >> On Sep 20, 2021, at 9:36 AM, Richard Earnshaw <Richard.Earnshaw@foss.arm.com> wrote: >> >> >> >> On 20/09/2021 14:55, Qing Zhao wrote: >>>> On Sep 20, 2021, at 8:18 AM, Richard Earnshaw <Richard.Earnshaw@foss.arm.com> wrote: >>>> >>>> >>>> >>>> On 20/09/2021 13:47, Qing Zhao wrote: >>>>>> On Sep 20, 2021, at 5:43 AM, Richard Earnshaw <Richard.Earnshaw@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. 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 >
> On Sep 20, 2021, at 10:59 AM, Richard Earnshaw <Richard.Earnshaw@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.Earnshaw@foss.arm.com> wrote: >>> >>> >>> >>> On 20/09/2021 14:55, Qing Zhao wrote: >>>>> On Sep 20, 2021, at 8:18 AM, Richard Earnshaw <Richard.Earnshaw@foss.arm.com> wrote: >>>>> >>>>> >>>>> >>>>> On 20/09/2021 13:47, Qing Zhao wrote: >>>>>>> On Sep 20, 2021, at 5:43 AM, Richard Earnshaw <Richard.Earnshaw@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
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.Earnshaw@foss.arm.com> wrote: > > > > On 20/09/2021 14:55, Qing Zhao wrote: >>> On Sep 20, 2021, at 8:18 AM, Richard Earnshaw <Richard.Earnshaw@foss.arm.com> wrote: >>> >>> >>> >>> On 20/09/2021 13:47, Qing Zhao wrote: >>>>> On Sep 20, 2021, at 5:43 AM, Richard Earnshaw <Richard.Earnshaw@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
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