Hi, Jakub,
> On Sep 16, 2021, at 4:19 AM, Jakub Jelinek <ja...@redhat.com> wrote:
>
> On Wed, Sep 15, 2021 at 05:59:08PM +0000, Qing Zhao wrote:
>>> Note, the gcc.dg/i386/auto-init* tests fail also, just don't have time to
>>> deal with that right now, just try
>>> make check-gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\}
>>> i386.exp=auto-init*'
>>
>> It’s strange that the above testing on my local x86 machine with the latest
>> gcc had less failure than the following:
>>
>> [opc@qinzhao-ol8u3-x86 build-boot]$ make check-gcc
>> RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} i386.exp=auto-init*' &> log &
>> [1] 3885164
>> [opc@qinzhao-ol8u3-x86 build-boot]$
>> [1]+ Done make check-gcc
>> RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} i386.exp=auto-init*' &> log
>> [opc@qinzhao-ol8u3-x86 build-boot]$ egrep FAIL gcc/testsuite/gcc/gcc.sum
>> FAIL: gcc.target/i386/auto-init-2.c scan-rtl-dump-times expand
>> "0xfffffffffefefefe" 2
>> FAIL: gcc.target/i386/auto-init-2.c scan-rtl-dump-times expand
>> "0xfefefefefefefefe" 3
>> FAIL: gcc.target/i386/auto-init-3.c scan-assembler-times pxor\t\\%xmm0,
>> \\%xmm0 3
>> FAIL: gcc.target/i386/auto-init-4.c scan-rtl-dump-times expand
>> "0xfffffffffefefefe" 1
>> FAIL: gcc.target/i386/auto-init-4.c scan-rtl-dump-times expand
>> "\\[0xfefefefefefefefe\\]" 1
>> FAIL: gcc.target/i386/auto-init-4.c scan-rtl-dump-times expand
>> "0xfffffffffffffffe\\]\\) repeated x16" 1
>> FAIL: gcc.target/i386/auto-init-5.c scan-assembler-times \\.long\t0 14
>> FAIL: gcc.target/i386/auto-init-padding-3.c scan-assembler movl\t\\$16,
>> FAIL: gcc.target/i386/auto-init-padding-3.c scan-assembler rep stosq
>> FAIL: gcc.target/i386/auto-init-padding-7.c scan-assembler-times movq\t\\$0,
>> 2
>> FAIL: gcc.target/i386/auto-init-padding-8.c scan-assembler-times movq\t\\$0,
>> 2
>> FAIL: gcc.target/i386/auto-init-padding-9.c scan-assembler rep stosq
>
> Testing for many instructions is always very fragile and dependent on exact
> compiler flags etc.
Yes, It’s indeed very fragile.
> So, either the test should have a particular
> -march=/-mtune= options
I might add specific -march to the testing cases.
> and ideally also -fno-stack-protector
> -fno-stack-clash-protection etc.
Could you explain a little bit on this why?
> if they could change the expected matching,
> or test it at runtime instead(I know, it is playing with fire, because you
> are testing the behavior of UB, but perhaps making the functions that use
> the uninitialized vars __attribute__((noipa)) and checking whether the vars
> contain the expected values might be ok.
I thought of doing the testing at runtime too in the beginning, however, I was
worried about how can we be sure that the correct values in the variable come
from the compiler initialization?
I will try one more time to see whether I can come up with a runtime testing
case.
Thanks a lot.
Qing
>
> Jakub
>
