[Bug target/113009] New: [14] RISC-V: gcc.c-torture/unsorted/dump-noaddr.c flakey tests

[Bug target/113009] New: [14] RISC-V: gcc.c-torture/unsorted/dump-noaddr.c flakey tests

[ewlu at rivosinc dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113009

            Bug ID: 113009
           Summary: [14] RISC-V: gcc.c-torture/unsorted/dump-noaddr.c
                    flakey tests
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ewlu at rivosinc dot com
  Target Milestone: ---

The following tests are flakey on newlib/linux for 32-bit and 64-bit vector
targets

FAIL: gcc.c-torture/unsorted/dump-noaddr.c.*r.avlprop,  -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions 
comparison
FAIL: gcc.c-torture/unsorted/dump-noaddr.c.*r.avlprop,  -O3 -g  comparison
FAIL: gcc.c-torture/unsorted/dump-noaddr.c.*r.reload,  -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  comparison
FAIL: gcc.c-torture/unsorted/dump-noaddr.c.*r.reload,  -O3 -g  comparison

With logs along the lines of 

line #8
< rescanning insn with uid = 213.
> rescanning insn with uid = 215.
line #9
< verify found no changes in insn with uid = 213.
> verify found no changes in insn with uid = 215.
line #10
< rescanning insn with uid = 215.
> rescanning insn with uid = 213.
line #11
< verify found no changes in insn with uid = 215.
> verify found no changes in insn with uid = 213.
FAIL: gcc.c-torture/unsorted/dump-noaddr.c.*r.avlprop,  -O3 -g  comparison

line #694
< changing reg in insn 215
> changing reg in insn 213
line #695
< changing reg in insn 213
> changing reg in insn 215
FAIL: gcc.c-torture/unsorted/dump-noaddr.c.*r.reload,  -O3 -g  comparison

Flakey tests bisected to r14-5744-gae098dfeeef though this is a rough estimate.
I only compiled and diffed the output 20 times for each hash during the
bisection so I might have just gotten lucky (or unlucky) when searching for the
"good" hash.

Command used:
./build-gcc-linux-stage2/gcc/xgcc -B./build-gcc-linux-stage2/gcc/  
-march=rv64gcv -mabi=lp64d -mcmodel=medlow   -fdiagnostics-plain-output  -w 
-O3 -g   -dumpbase dump1/dump-noaddr.c -DMASK=1 -x c --param ggc-min-heapsize=1
-fdump-ipa-all -fdump-rtl-all -fdump-tree-all -fdump-noaddr
-gno-record-gcc-switches -c   -o
./build-gcc-linux-stage2/gcc/testsuite/gcc/dump-noaddr.o
../gcc/gcc/testsuite/gcc.c-torture/unsorted/dump-noaddr.c && diff -d
dump1/dump-noaddr.c.*r.avlprop
../../baseline/build-flakey/dump1/dump-noaddr.c.302r.avlprop

All recorded instances can be found here:
https://github.com/patrick-rivos/gcc-postcommit-ci/issues?q=FAIL%3A+gcc.c-torture%2Funsorted%2Fdump-noaddr.c.*r.avlprop%2C+-O3+-g+comparison+

[Bug target/113009] [14] RISC-V: gcc.c-torture/unsorted/dump-noaddr.c flakey tests

[ewlu at rivosinc dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113009

--- Comment #1 from Edwin Lu <ewlu at rivosinc dot com> ---
Found issue with bisection script. Currently re-bisecting

[Bug target/113009] [14] RISC-V: gcc.c-torture/unsorted/dump-noaddr.c flakey tests

[ewlu at rivosinc dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113009

Edwin Lu <ewlu at rivosinc dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |juzhe.zhong at rivai dot ai

--- Comment #2 from Edwin Lu <ewlu at rivosinc dot com> ---
Re-bisected to r14-6197-g2e7abd09621

Full steps to reproduce:
mkdir dump1
./build-gcc-linux-stage2/gcc/xgcc -B./build-gcc-linux-stage2/gcc/  
-march=rv64gcv -mabi=lp64d -mcmodel=medlow   -fdiagnostics-plain-output  -w 
-O3 -g   -dumpbase dump1/dump-noaddr.c -DMASK=1 -x c --param ggc-min-heapsize=1
-fdump-ipa-all -fdump-rtl-all -fdump-tree-all -fdump-noaddr
-gno-record-gcc-switches -c   -o
./build-gcc-linux-stage2/gcc/testsuite/gcc/dump-noaddr.o
../gcc/gcc/testsuite/gcc.c-torture/unsorted/dump-noaddr.c
mv dump1 dump1-comp
mkdir dump1
for i in {1..100}; do 
  ./build-gcc-linux-stage2/gcc/xgcc -B./build-gcc-linux-stage2/gcc/  
-march=rv64gcv -mabi=lp64d -mcmodel=medlow   -fdiagnostics-plain-output  -w 
-O3 -g   -dumpbase dump1/dump-noaddr.c -DMASK=1 -x c --param ggc-min-heapsize=1
-fdump-ipa-all -fdump-rtl-all -fdump-tree-all -fdump-noaddr
-gno-record-gcc-switches -c   -o
./build-gcc-linux-stage2/gcc/testsuite/gcc/dump-noaddr.o
../gcc/gcc/testsuite/gcc.c-torture/unsorted/dump-noaddr.c && diff -d
dump1/dump-noaddr.c.*r.avlprop ./dump1-comp/dump-noaddr.c.*r.avlprop; 
done

may take around 2-3 min for the diff output to start appearing depending on
whether the expected output is saved into dump-comp or not

[Bug target/113009] [14] RISC-V: gcc.c-torture/unsorted/dump-noaddr.c flakey tests

[juzhe.zhong at rivai dot ai]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113009

--- Comment #3 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to Edwin Lu from comment #2)
> Re-bisected to r14-6197-g2e7abd09621
> 
> Full steps to reproduce:
> mkdir dump1
> ./build-gcc-linux-stage2/gcc/xgcc -B./build-gcc-linux-stage2/gcc/  
> -march=rv64gcv -mabi=lp64d -mcmodel=medlow   -fdiagnostics-plain-output  -w 
> -O3 -g   -dumpbase dump1/dump-noaddr.c -DMASK=1 -x c --param
> ggc-min-heapsize=1 -fdump-ipa-all -fdump-rtl-all -fdump-tree-all
> -fdump-noaddr -gno-record-gcc-switches -c   -o
> ./build-gcc-linux-stage2/gcc/testsuite/gcc/dump-noaddr.o
> ../gcc/gcc/testsuite/gcc.c-torture/unsorted/dump-noaddr.c
> mv dump1 dump1-comp
> mkdir dump1
> for i in {1..100}; do 
>   ./build-gcc-linux-stage2/gcc/xgcc -B./build-gcc-linux-stage2/gcc/  
> -march=rv64gcv -mabi=lp64d -mcmodel=medlow   -fdiagnostics-plain-output  -w 
> -O3 -g   -dumpbase dump1/dump-noaddr.c -DMASK=1 -x c --param
> ggc-min-heapsize=1 -fdump-ipa-all -fdump-rtl-all -fdump-tree-all
> -fdump-noaddr -gno-record-gcc-switches -c   -o
> ./build-gcc-linux-stage2/gcc/testsuite/gcc/dump-noaddr.o
> ../gcc/gcc/testsuite/gcc.c-torture/unsorted/dump-noaddr.c && diff -d
> dump1/dump-noaddr.c.*r.avlprop ./dump1-comp/dump-noaddr.c.*r.avlprop; 
> done
> 
> may take around 2-3 min for the diff output to start appearing depending on
> whether the expected output is saved into dump-comp or not

Thanks for reporting it.  I will take a look at it.
That commit is to fix ICE and execution issues (real bugs).

We are busy with fixing real bugs (ICE and execution FAILs) on full coverage
testing.
Dump FAILs are bogus FAILs, it's low priority for now.

[Bug target/113009] [14] RISC-V: gcc.c-torture/unsorted/dump-noaddr.c flakey tests

[ewlu at rivosinc dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113009

--- Comment #4 from Edwin Lu <ewlu at rivosinc dot com> ---
(In reply to JuzheZhong from comment #3)
> (In reply to Edwin Lu from comment #2)
> > Re-bisected to r14-6197-g2e7abd09621
> > 
> > Full steps to reproduce:
> > mkdir dump1
> > ./build-gcc-linux-stage2/gcc/xgcc -B./build-gcc-linux-stage2/gcc/  
> > -march=rv64gcv -mabi=lp64d -mcmodel=medlow   -fdiagnostics-plain-output  -w 
> > -O3 -g   -dumpbase dump1/dump-noaddr.c -DMASK=1 -x c --param
> > ggc-min-heapsize=1 -fdump-ipa-all -fdump-rtl-all -fdump-tree-all
> > -fdump-noaddr -gno-record-gcc-switches -c   -o
> > ./build-gcc-linux-stage2/gcc/testsuite/gcc/dump-noaddr.o
> > ../gcc/gcc/testsuite/gcc.c-torture/unsorted/dump-noaddr.c
> > mv dump1 dump1-comp
> > mkdir dump1
> > for i in {1..100}; do 
> >   ./build-gcc-linux-stage2/gcc/xgcc -B./build-gcc-linux-stage2/gcc/  
> > -march=rv64gcv -mabi=lp64d -mcmodel=medlow   -fdiagnostics-plain-output  -w 
> > -O3 -g   -dumpbase dump1/dump-noaddr.c -DMASK=1 -x c --param
> > ggc-min-heapsize=1 -fdump-ipa-all -fdump-rtl-all -fdump-tree-all
> > -fdump-noaddr -gno-record-gcc-switches -c   -o
> > ./build-gcc-linux-stage2/gcc/testsuite/gcc/dump-noaddr.o
> > ../gcc/gcc/testsuite/gcc.c-torture/unsorted/dump-noaddr.c && diff -d
> > dump1/dump-noaddr.c.*r.avlprop ./dump1-comp/dump-noaddr.c.*r.avlprop; 
> > done
> > 
> > may take around 2-3 min for the diff output to start appearing depending on
> > whether the expected output is saved into dump-comp or not
> 
> Thanks for reporting it.  I will take a look at it.
> That commit is to fix ICE and execution issues (real bugs).
> 
> We are busy with fixing real bugs (ICE and execution FAILs) on full coverage
> testing.
> Dump FAILs are bogus FAILs, it's low priority for now.

While it is a dump failure, there is some non-determinism in the compilation.
Running the same executable on the same piece of code should not try compiling
it differently every time.

[Bug target/113009] [14] RISC-V: gcc.c-torture/unsorted/dump-noaddr.c flakey tests

[juzhe.zhong at rivai dot ai]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113009

--- Comment #5 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
I don't see this dump FAIL in the trunk now.

Could you confirm it ?

[Bug target/113009] [14] RISC-V: gcc.c-torture/unsorted/dump-noaddr.c flakey tests

[ewlu at rivosinc dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113009

Edwin Lu <ewlu at rivosinc dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #6 from Edwin Lu <ewlu at rivosinc dot com> ---
(In reply to JuzheZhong from comment #5)
> I don't see this dump FAIL in the trunk now.
> 
> Could you confirm it ?

Ran 1000 times on r14-6596-g7d7a480eedf and don't see it anymore. Thanks!