RISC-V Pioneer Box for builder.sourceware.org gcc CI

[Jeff Law]

On 8/8/24 9:13 AM, Mark Wielaard wrote:

> 
> But I don't fully understand how the gcc testsuite detects whether rvv
> is implemented. e.g. rvv.exp seems to just check whether the target is
> RISC-V and if so just executes all tests assuming it can just set
> -march=rv64gcv* and/or -mrvv-* and run the tests:
> 
> # Exit immediately if this isn't a RISC-V target.
> if ![istarget riscv*-*-*] then {
>    return
> }
> 
> Should that test be more precise? Or is there some other test that is?
There's some bits to avoid run tests on targets that don't support V. 
But they may need adjustment to deal with those V0.7.1 systems.

> 
> I do see some of the runtime tests have:
> /* { dg-do run { target { riscv_v } } } */
> 
> How exactly does that work? How does it determine the riscv_v target?
It's all buried inside target-supports.exp.  How it all works, I don't 
know offhand.  It just seems to work for me, but most of what I do is 
cross builds, but QEMU+binfmt to allow running the risc-v binaries 
seamlessly.  When I use the milkv, it's usually for something like 
stack-clash testing to verify Raphael's work mitigates the stack-clash 
vulnerabilities.

> 
> 
> I put an extra fan on it. It has been pretty stable. Last couple of
> days it has been doing back-to-back gcc bootstaps. Which now take ~5
> hours about half of the time it is actually using 64 cores at the same
> time, but it is also running a lot of time just one or a few cores.
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402
Sounds good.  I was speaking with Palmer earlier this week.  They 
apparently fried a few of these systems already.  It sounds like what 
happens isn't in-flight corruption of data traversing pcie.  Instead it 
actually fries the pcie switch itself.  So once it's overheated, you've 
effectively busted your board.  Palmer indicated that they're using NFS 
to keep their systems usable :-)

And yes, there are extreme serialization events in the build.  The 
vector implementation for riscv really makes that problem worse. 
insn-recog, insn-output, insn-attrtab and their associated generation 
step can take significant time.

jeff