On 5/16/23 18:29, Palmer Dabbelt wrote:
On Tue, 16 May 2023 18:04:37 PDT (-0700), Vineet Gupta wrote:
+ Christoph, Jiawei
On 5/16/23 17:20, Palmer Dabbelt wrote:
We really need to add some CI around RV toolchains to trip on these
sooner !
Sounds like you're volunteering to set one up?
Patrick's github CI patch seems to be a great start. Lets wait for it to
get merged, that will at least catch rv toolchain snafus: although the
granularity of testing is not ideal (tc changes are not so frequent)
You mean riscv-gnu-toolchain changes? That's not super useful for GCC
development, they're on a fork.
Well they are still useful to catch various snafus in toolchain plumbing
itself - I've run into 2 of those and Patcrick 2 himself, when trying to
use latest upstream toolchain scripts. But sure they are not testing
bleeding edge gcc.
I think the most pressing need is bleeding edge gcc regression tracking.
@Jeff is anything setup on sourceware and/or usable ? I thought they
do have existing bots for some arches to spin up build / run - perhaps
runs are native and not qemu.
IIRC Jeff said his builders were hanging right now.
Jeff it seems has his own test infra. I was asking if sourceware (or
whatever the custodian of gcc project has).
I'd be really surprised if primary arches such as x86/aarch64 don't have
any test bots there ?
FWIW rivos gitlab CI (not public) has capability to track upstream gcc
(Kevin almost has it working), but there is no easy way to publish it
for rest of the world and I'd rather that be done in a public infra.
+Kevin
At least having the failure lists public would be a must-have, and I
think that's tricky to do with gitlab.
Yep.
Bjorn and Conor have something glued to the kernel patchwork that
uploads test results to github as snippits, but IIRC we're trying to
replace it with something more directly visible.
Didn't ISCAS/PLCT have such infra - sorry Kito asked the same question
this morning, but I was not fully awoke so don't remember what Jiawei
replied.
I didn't even remember he asked ;)
