On 8/13/25 12:53 AM, Richard Biener via Gcc wrote:
Having testresults also shows the port builds (as a cross at least) and is
able to build its target libraries. IMO broken ports are worse than
unmaintained ones, esp. if we release with those.
Right.
Ideally we'd have build bots with publically visible results that test
the building part
(doesn't have to run often), this should include building
cross-binutils, newlib/glibc/avr-libc
as fit.
I actually had a public link to mine, but it didn't seem like anyone
ever looked at the results, so when things got juggled a while back I
never restored consistent external access.
It's possible to churn through all those embedded targets daily given a
pair of circa 2020 servers. Build binutils, build gcc/libgcc, build
newlib, run check-gcc, move on to the next target.
Similarly for the various linux-gnu targets without QEMU user mode
emulation. Those churn through quickly.
THe only thing that takes a long time are bootstraps of the QEMU
emulated targets. alpha, m86k, hppa, sh4, s390, ppc etc. Those take
~24hrs each.
H8 takes ~8hrs as well, but that's a problem with the simulator's
decoder being uber-dumb and I don't have the time/interest to fix it.
That said, I'd like to move away from gcc-testresults as a vetting
tool to something
more modern. Possibly a good(?) GSoC project, set up github CI
runners for this?
Yes, it'd be a fine GSoC project. Getting it set up is the easy part,
the monitoring of results to address regressions is the recurring cost.
But I've also found it invaluable for testing in-flight work across a
variety of targets.
jeff
