As can be seen on the snapshots page ("sdcc-snapshot-aarch64-unknown-freebsd13.1-20230715-14232.tar.bz2"), some of the regression tests are failing for Debian GNU/Linux on aarch64: Lots of test-ucz80, some of test-ez80-z80, test-ucr2k, test-stm8-large and test-dpk15-stack.-auto.
I've done an in-tree build on the same machine (a Raspi 4), but I only see a small number of failures for test-ucz80 (all of them float func stuff), but the others pass.
And the small number of failures that I do see in the in-tree test are not really reproducible: I just looked into a test failure today, tracked it down to the exact wrong line in the generated asm. Then rerun the compiler with the same options, and the result was correct! valgrind doesn't show any reads of uninitialized memory either.
The failures appeared around the time the next and genconstprop branches were merged to trunk. They only affect the Raspi 4 running Debian GNU/LInux, not the FreeBSD one.
I wonder if I am seeing bitflips: Rowhammer research indicates that they are far more common on Raspi4 than on previous Raspis.
P.S.: I upgraded Debian on the Raspi4 to latest bookworm, rebooted it, ran memtester a bit. No errors found so far. I'll rebuild sdcc and rerun tests. Later maybe also run memtester while doing the regression tests (in case the problem only happens during high system load).
Last edit: Philipp Klaus Krause 2023-07-29
I still see those problems. This time,
__fseq
for z80n was affected. After a recompile, the code then looked fine. This is the diff from the correct, to the incorrect version:As we can see (and this is the same problem that I saw in the asm for other functions for other targets earlier), at some places a
#0x00
is used instead of the actual variable. Since the problem appeared after merging the genconstprop branch to trunk, the by far most likely cause is that information from generalized constant propagation is incorrect at the time it is used in code generation, in particularaop->valinfo.knownbitsmask
when used inaopIsLitVal
.I do not know where it goes wrong - it could be during generalized constant propagation analysis, or at a later time up to code generation. valgrind still does not show any reads of uninitialized memory, though, so I wonder why the bug cannot be reproduced reliably.
I've found and fixed some issues that might have caused this; while the failures seem less common now, there still are some.
Now I'm using SDCC instrumented with sanitizers, and hope that will help. Even if it doesn't fix this bug, I've already found a few more issues in SDCC, so the effort will improve SDCC code quality.
Since today's round of UB fixes in [r14254], I haven't seen these test failures again.
But I better rerun the test again (and wait for results on the snapshots page) to be more confident.
Related
Commit: [r14254]
I haven't seen failures in three round of regression testing on an (in-tree) build of sdcc. But there are still failures on the snaphots page (which does an out-of-tree build, though I have no idea if that makes the difference).
Fixed recently: [r14369].
Related
Commit: [r14369]