-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Questions about the test suite #1579
Comments
Further results:
|
FWIW - another test run...
|
And a run with the Linux/glibc toolchain:
|
Does anybody (@cmuellner or @kito-cheng perhaps?) know why I'm getting the results above with the latest of everything from this repo? |
@pz9115 would you like to check this issue and provide some inputs? |
If you need me to provide any clarification or do any additional tests please let me know. |
Hi @TommyMurphyTM1234 If you try some gcc modification, then regression testing is necessary. In comparison, gcc's regression testing time is much longer than other components (such as binutils). The more errors a regression test has, the longer it takes to run(I guess it's because some of the execution tests are not responding in the simulator). So it is a good choice that only run riscv related testcases in gcc part. You can use I usually run two types of regression tests, one using glibc and one using newlib, which use --with-arch=rv64gc as their base argument. It fine for mostly changes undenpend new sub-extension. Hope this will help you:) |
Thanks @pz9115. I understand the general rationale for the test suite and acknowledge that my runs here are "artificial" and strictly unnecessary because I'm not actually testing before and after any changes to stuff like GCC, Binutils, C library etc. However, my other questions still stand and have not been addressed. In particular, why does the test suite seem to fail and generate errors with the latest repo contents? Isn't that indicative if something anomalous? As far as I can see there isn't a baseline "successful" test suite run right now against which tests on a modified version of the toolchain can be compared. |
For the failed cases, you can check the detail in the test log, which in the |
OK - but what about stuff like this where
So the recommended target for testing is QEMU and not Spike? I thought that several changes/PRs were checked by running the test suite against Spike? It seems to me that there is a severe lack of instructions/documentation on the specifics of how best/correctly to run the test suites against the |
I still have some confusion about the test suite...
In the case of a change/PR that needs to be tested what are the recommendations for running the test suite? For example - what simulator (Spike or QEMU - or maybe it depends on the nature of the changes requiring testing?), what toolchain(s) (e.g. bare-metal versus Linux/glibc, multilib or not, etc.), what
arch/abi
(s) (e.g. defaultrv64gc/lp64d
versusrv32gc/ilp32d
versus, say,rv32imac/ilp32
etc.)?On the modest hardware that I have access to (e.g. up to i5 gen 8) the test suite takes a very, very long time to run - so long, in fact, that it's not really practical to run it much if at all. Is there any way to accelerate the running of the test suite or are there any other options such as cloud based testing. GitHub actions etc.?
Is there any friendly guide to understanding the basics of what the test suite does, how it works and how to deal with things like test results/reports and exclusion config files? Or is it simply a case of reading upstream info about the GCC test suite, DejaGnu etc.?
(This may merit a separate issue?) When I cloned the latest
riscv-gnu-tools
repomaster
branch and tried to run the test suite I seem to have got incorrect results. Does this indicate a problem with how I am running it or are these failures "real"? See below for details.(The test suite is still running after many, many hours so I cannot post the C++ test results summary or the full test log yet).
The text was updated successfully, but these errors were encountered: