On Sat, 10 Mar 2018 at 12:30 AM, Philippe Mathieu-Daudé <f4...@amsat.org> wrote:
> Hi Michael, > > On 03/09/2018 12:17 PM, Michael Clark wrote: > > On Fri, 9 Mar 2018 at 11:45 PM, Peter Maydell <peter.mayd...@linaro.org> > > wrote: > > > >> On 9 March 2018 at 04:22, Michael Clark <m...@sifive.com> wrote: > >>> I need to dig into this. I'll need to take the assertions out, or run > >> with > >>> tracing to see which fcvt test is triggering this unreachable piece of > >>> code. FYI. I can look into it. > >> > >>> > >> > ERROR:/Users/mclark/src/sifive/riscv-qemu/fpu/softfloat.c:1374:round_to_int_and_pack: > >>> code should not be reached > >>> qemu-images/run-tests.sh: line 6: 58437 Abort trap: 6 ${QEMU} > >>> -nographic -machine spike_v1.10 -kernel $i > >> > >> This looks like maybe it's the issue Richard Jones sent a patch for ? > >> https://lists.gnu.org/archive/html/qemu-devel/2018-03/msg01005.html > > > > > > Thanks. Seems I wasn’t on the ‘cc. > > > > We need this patch in our downstream repo... We also need to automate > > riscv-tests in the riscv.org repo .travis.yml so we can pick these > things > > up automatically... > > What about upstreaming the QEMU part of your .travis.yml? We can. It will add overall test coverage as we exercise a lot of the TCG instrinsics. I’m currently working on dependencies which is having the riscv-toolchains .travis.yml create toolchain packages in Docker when tagged using the Travis/GitHub deployment Integration. The riscv-tests repo can then pull the toolchain into a Docker/repo to build a binary image of the tools which it can then upload using the same Travis/GitHub deployment integration. Unfortunately i’m trying to split my time amongst some CI work on the other riscv.org repos that i’ve not yet got integrated. My toolchain build recipe takes 3 hours to make .deb and .rpm multilib toolchain packages on tagging, which is way beyond the Travis timeouts so i’m exploring some hosted builds someware, e.g. an AWS instance. I could just upload binaries manually but we were planning to have this integrated into GitHub/Travis with tag hooks. We have tested this on some repositories already, but the toolchain is the main dependency for all of the other repos to build binary test images that are publicly available. Currently I have a local set of binaries for testing and it’s adhoc. i.e. not triggered automatically when we create a tag in one of the repos. We don’t have anyone dedicated to CI so it’s a task I am working on when time is available... Hopefully we’ll have binary images for the various artefacts on the Releases section on all of the riscv repos, or maybe SiFive will do this in its own repos. It’s sorely needed as currently everyone has to build everything from scratch. It takes a lot of time and effort to reproduce a set of test binaries for riscv-tests, riscv-linux, riscv-pk/bbl and SiFive’s own E and U series SDKs. The git repos are constantly changing so the only way at present is to track many repos and rebuild binaries. It will be great when binaries are included with the GitHub Releases/tags assuming we use GitHub Releases to host the binaries. I really want to spend time on this because I think the current CI setup is less than ideal. I’m frustrated by my own humanity which is by nature to err, which means sometime forgetting to run exhaustive tests on each release. The obvious solution is to wire the tests into the CI so bots take care of this. Michael