On 5/27/2026 3:30 AM, Richard Braun wrote:
On Fri, May 08, 2026 at 04:17:36PM -0600, Jeffrey Law wrote:
One more note. I've got a standard setup that allows me to test that the
c6x code generator isn't aborting, segfaulting and the like. It can't test
the correctness of the generated code as there's not gdbsim or qemu port for
c6x. But it's better than nothing. So if you've got something you want
tested, pass it along as a patch and I can throw it in.
Hello,
I'm starting work on this again, and I'd like to know your testing
procedure, if it's not too complicated to communicate, so I can reproduce
those issues and fix them. I assume many of those are fixed by the last
two patches on the branch, but I'd like to know if there's more, and
maybe fix that too.
My tester does the usual build binutils, minimal gcc & target libraries,
then newlib.
Once the build is done it does a traditional make check-gcc (so it only
tests C, not C++, Fortran, etc).
It'll use gdbsim/qemu for simulation if available. If no simulator is
available, then a dummy simulator that always signals success is used.
That allows us to at least compile & link the execution tests, even on
limited targets. It supports nearly every cpu family supported by GCC.
For targets which can run linux, it does bootstrap & regression
testing (using either real hardware or a qemu user mode emulation).
I have a mechanism to add patches to that system for testing purposes.
I personally use it for testing my own bits before officially submitting
them, but I also add patches for testing when working with others.
So if you have a patch you want me to spin, reach out. I just need the
patchfile and if it only touches a single target like the c6x files,
then the build/test cycle is < 1hr.
Jeff
