https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122493
--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
As for the other 2:
> FAIL: gcc.dg/tree-ssa/ssa-dom-thread-7.c scan-tree-dump thread2 "Jumps
> threaded: 8"
> FAIL: gcc.dg/tree-ssa/ssa-sink-18.c scan-tree-dump-times sink2 "Sunk
> statements: 5" 1
ssa-dom-thread-7.c just needs an update to how many jumps are threaded, now 12.
What cfg cleanup is doing is correct, the forwarder blocks all are ones with
MEM PHIs too :).
ssa-sink-18.c still need to understand what this is testing, we do sink only
one statement instead of 5 now. Doesn't sink need the critical edge split to
work? sink does that already via split_edges_for_insertion . Still trying to
understand what is going on here.
We do sink still:
Sinking op_215 = op_244 + 2;
from bb 62 to bb 93
But the IVopts related ones are not though:
Sinking _378 = (uint8_t *) _274;
from bb 45 to bb 47
Sinking _274 = ivtmp.23_268 + _273;
from bb 45 to bb 47
Sinking _273 = (unsigned long) ip_241;
from bb 45 to bb 47
Sinking len_167 = _272 + 4294967295;
from bb 45 to bb 47
The comment says:
/* For this case, pass sink2 sinks statements from hot loop header to loop
exits after gimple loop optimizations, which generates instructions
executed
each iteration in loop, but the results are used outside of loop:
With -m64,
"Sinking op_230 = op_244 + 2;
from bb 63 to bb 94
Sinking _367 = (uint8_t *) _320;
from bb 31 to bb 90
Sinking _320 = _321 + ivtmp.25_326;
from bb 31 to bb 90
Sinking _321 = (unsigned long) ip_229;
from bb 31 to bb 90
Sinking len_158 = _322 + 4294967295;
from bb 31 to bb 33"
When -m32, Power and X86 will sink 3 instructions, but arm ilp32 couldn't
sink due to ivopts chooses two IV candidates instead of one, which is
expected, so this case is restricted to lp64 only so far. This different
ivopts choice affects riscv64 as well, probably because it also lacks
base+index addressing modes, so the ip[len] address computation can't be
made from the IV computation above. powerpc64{,le} similarly is affected.
*/
And here are the other testcases that fail that need to be looked more into
also:
```
+FAIL: c-c++-common/unroll-1.c -Wc++-compat scan-rtl-dump loop2_unroll
"3[79]:.*: optimized: loop unrolled 2 times"
+FAIL: c-c++-common/unroll-2.c -Wc++-compat scan-rtl-dump loop2_unroll
"3[79]:.*: optimized: loop unrolled 2 times"
+FAIL: c-c++-common/unroll-3.c -Wc++-compat scan-rtl-dump loop2_unroll
"3[79]:.*: optimized: loop unrolled 2 times"
+FAIL: gcc.dg/pr81165.c scan-tree-dump-not optimized " [/%] "
+FAIL: gcc.dg/uninit-pr40635.c (test for warnings, line 32)
+FAIL: gcc.dg/uninit-pr40635.c (test for excess errors)
+FAIL: gcc.dg/uninit-pred-7_a.c bogus warning (test for bogus messages, line
23)
+FAIL: gcc.target/i386/pr121062-1.c scan-assembler-times movq[ \\\\t]+\\\\\$-1,
%r[a-z0-9]+ 2
+FAIL: g++.dg/uninit-pred-5.C -std=gnu++17 (test for warnings, line 44)
+FAIL: g++.dg/uninit-pred-5.C -std=gnu++26 (test for warnings, line 44)
+FAIL: g++.dg/uninit-pred-5.C -std=gnu++98 (test for warnings, line 44)
```
gcc.dg/pr81165.c might be a jump threading regression ... The rest I have to
look more into depth.
