Fix _unsafe_trunc for BigFloat on ARM

[kimikage]

Fixes #202.

This also moves _unsafe_trunc to "src/utilities.jl". It has been used in ”fixed.jl" for 2 years.

FixedPointNumbers.jl/src/fixed.jl

Line 53 in 39d4687

reinterpret(U, _unsafe_trunc(T, y))

---

I didn't have the plans, but I'd like to release v0.8.4.

[codecov]

Codecov Report

Merging #203 into master will decrease coverage by 0.38%.
The diff coverage is 42.85%.

@@            Coverage Diff             @@
##           master     #203      +/-   ##
==========================================
- Coverage   89.30%   88.91%   -0.39%     
==========================================
  Files           6        6              
  Lines         458      460       +2     
==========================================
  Hits          409      409              
- Misses         49       51       +2     

Impacted Files	Coverage Δ
src/normed.jl	89.72% <ø> (+0.84%)	⬆️
src/utilities.jl	84.00% <33.33%> (-16.00%)	⬇️
src/fixed.jl	90.17% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3f12729...65049ad. Read the comment docs.

[kimikage]

The tests were passed on ARM.
https://travis-ci.com/github/kimikage/FixedPointNumbers.jl/builds/176247519

Since this package is low-level and Linux-aarch64 is in Tier 1, I think it might be a good idea to add aarch64 into the CI targets. However, the arm64 environment in Travis may differ from the practical environment because it does not support any extension instruction sets such as NEON.

[johnnychen94]

However, the arm64 environment in Travis may differ from the practical environment because it does not support any extension instruction sets such as NEON.

Even if it is not a perfect setting, adding aarch64 as one CI target could definitely improve the code coverage and help catches potential issues. So why not 😄

[kimikage]

My little concern is that the arm64 environment in Travis is a bit slow.

Maybe:

• GitHub Actions
  • { Linux, Windows, macOS } × { v1.0, v1, nightly } × { x64 } ∪ { (Windows?, v1, x86) }
• Travis CI
  • { Linux } × { v1.0, v1, nightly } × { aarch64 }
• AppVeyor
  • Thank you for everything!

[johnnychen94]

Windows x86 is no-longer at tier 1 support, so it makes sense to not include it in CI. I'm not 100% sure of it, though.

JuliaLang/www.julialang.org#667

{ Linux, Windows, macOS } × { v1.0, v1, nightly } × { x86-64 }

I assume this is arch = [x86, x64]?

[kimikage]

I assume this is arch = [x86, x64]?

I meant arch = x64 only. I think testing on 32-bit x86 is necessary, but I don't think it's necessary to consider OS differences. Therefore, the OS for 32-bit x86 does not have to be Windows.

[timholy]

I don't follow architectures carefully but I'd support adding a new one to tests. How long are we talking to run the tests on aarch64?