Re: [Qemu-devel] Apparently fpu/softfloat.c:1374 is reachable

[Michael Clark]

On Sat, 10 Mar 2018 at 12:30 AM, Philippe Mathieu-Daudé <address@hidden>
wrote:

> Hi Michael,
>
> On 03/09/2018 12:17 PM, Michael Clark wrote:
> > On Fri, 9 Mar 2018 at 11:45 PM, Peter Maydell <address@hidden>
> > wrote:
> >
> >> On 9 March 2018 at 04:22, Michael Clark <address@hidden> 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