Add ARMv7 as CI test target

[ghost]

This adds ARMv7 as test target for Travis CI so that issues on this 32-bit platform can be spotted immediately which should also resolve #43.

To do so, I opted to bump the CI to Xenial to avoid needing third-party repositories as everything just works using crossbuild-essential-armhf and qemu-user-static on this platform.

I also to install packages using sudo apt-get instead of the APT addon as the latter does not support conditional installs based on the build matrix, but I did not want to use a different installation method of the conditional and the unconditional dependencies.

Note that the spec tests currently fail due to failures in wasm_conversions. I would be glad if someone could help me with fixing those.

[parity-cla-bot]

It looks like @adam-rhebo signed our Contributor License Agreement. 👍

Many thanks,

Parity Technologies CLA Bot

[pepyakin]

Ok, this turned out to be trickier that I initially thought.

The test that fails is this one.

It tests i32.trunc_f32_s instruction,

• here is the general conversion instruction description.
• here is the specific operator description.

This is the implementation of the opcode and it looks like the problem is in this code:

https://github.com/paritytech/wasmi/blob/284c907b29a358d8345c1884dcbfb3e3b661185f/src/value.rs#L372-L385

The comment mentions that it is UB to convert value such as Inf or NaN. However, it also looks like that it is UB to convert a value that is outside of range of the target type, see rust-lang/rust#10184.

I briefly tried to fix it by adding explicit bounds check but it didn't help. I guess there is a chance that something else might be going on, but I don't have ARM hardware nearby nor don't have a lot of time to look into it. If you decide to fix this and bump into problems feel free to ask me questions.

[ghost]

@pepyakin I had a look and I think anything that tries to detect the failed conversions using self as $into will not work as the UB already happened at that point. Hence I pushed a variant that uses arbitrary precision numbers from the num crate to perform the conversion which surely has worse performance, but does yield correct results. This can probably go away again when the upstream issue is resolved.

I am not completely sure, but I guess the same could be applied to impl_wrap_into!(f64, f32);?

[ghost]

@pepyakin I had to check the cross-compiled tests to use --release builds as they would hit the Travis CI build timeouts otherwhise. Normally, this would be unfortunate as it makes for less useful stack traces, but since the tests run under qemu-arm-static, the stack traces are already not very useful...

[pepyakin]

But otherwise seems good!

UPD: let me expand a bit. Since:

1. this project more values correctness over performance
2. tries to let people experiment with wider range of platforms
3. use cases of paritytech don't require floats

I am inclined to trade off some performance in order to support more platforms. If anybody comes up with a better way to do this I'd be happy to merge it.

[ghost]

If anybody comes up with a better way to do this I'd be happy to merge it.

Ideally, rustc will be improved after LLVM has the necessary intrinsics and we will get things like impl TryFrom<f32> for i32 which we can then just use here instead of the arbitrary precision numbers.

[pepyakin]

Yeah.

But TBH I am still not sure why checking the range before casting doesn't work (as in my tentative fix). I still think that it might be possible to solve it this way.

[ghost]

But TBH I am still not sure why checking the range before casting doesn't work (as in my tentative fix). I still think that it might be possible to solve it this way.

From my debugging, I saw that the value actually was in range, i.e. for x86-64 and arm, self.truncate() <= $into::max_value() as $from was always true. On x86-64, however, self.truncate() had a different sign bit from (self as $into) as $from which did not held on arm. This is completely "valid" as self as $into is already UB.