InexactError: Int64(1.0) on macOS Apple Silicon CI runners when using an x86_64 julia binary (via. rosetta)

[lmiq]

I experienced this (non-reproducible) error in a CI run on the pre release (1.11 now), in the MacOS platform:

 ERROR: LoadError: TaskFailedException

    nested task error: InexactError: Int64(1.0)

The line where the error occurred was:

            index = floor(Int, xi) + 1

in which xi is a Float64. As far as I understand, the result of floor should always return an exactly representable Int, so the error should not occur.

When reporting this on Zulip, it, @jlumpe (sorry if the tag is wrong), reported having observed two times similar errors:

https://github.com/mikeingold/MeshIntegrals.jl/actions/runs/10965929580/job/30452792024?pr=73#step:7:191
https://github.com/JoshuaLampert/DispersiveShallowWater.jl/actions/runs/10811172112/job/29990016675?pr=150#step:7:8511

But these with 1.10.

Thus, although hard to reproduce, might be something worth investigating.

[oscardssmith]

something is obviously going horrifically wrong here. It will be very hard to reproduce without an RR trace.

[mbauman]

Are you using xi in a muladd in your case? In the linked CI runs, both are happening in cospi or sincospi, where the nearby muladd looks suspiciously like it might result in something like #55785?

[oscardssmith]

the really confusing thing here is that the error message shows the number as being an int...

[lmiq]

The function where the error appeared for me was this one:

@inline function particle_cell(x::SVector{N}, box::Box) where {N}
    CartesianIndex(
        ntuple(N) do i
            xmin = box.computing_box[1][i]
            xi = (x[i] - xmin) / box.cell_size[i]
            index = floor(Int, xi) + 1
            return index
        end
    )
end

(from here: https://github.com/m3g/CellListMap.jl/blob/f85ede5118462331d23303833249f84ac6942ff3/src/Box.jl#L584)

[giordano]

Tangentially related, since as far as I understand @testset sets the RNG status internally, it'd be nice if @testset also printed the RNG status to let people reproduce the failure.

[lmiq]

Unfortunately I rerun the job and I can't reproduce it, but I'm using StableRNGs. So I'm not sure if that would really help.

[mbauman]

the really confusing thing here is that the error message shows the number as being an int

Yes, that's very fast-mathy. Int conversion does the following:

    %1 = call double @llvm.trunc.f64(double %0)
    %2 = fsub double %0, %1
    %3 = fcmp une double %2, 0.000000e+00
    br i1 %3, label %error_path, label %ok_path

And then the %error_path uses %0. If that fsub fuses into an fma with an inlined/prior multiplication to create %0, you could get a different answer for the br. But this should be reproducible with a stable RNG, so it may be a red herring.

[giordano]

That's not annotated contract though, is it?

[mbauman]

Correct. This could be dependent upon surrounding code if it inlines, but neither sinpi nor sincospi inline, so I don't think this is reason here.

[oscardssmith]

even if it is, that doesn't actually explain anything. This error can only occur if the compiler proves that xi is outside of [-0x1p63, 0x1p63) which 1.0 obviously isn't, so this bug requires a pretty dramatic miscompile.

[lmiq]

I got the error again in this workflow run:

https://github.com/m3g/ComplexMixtures.jl/actions/runs/11390346140/job/31691748110#step:6:972

[oscardssmith]

does RR work for Mac? I really want to see what is going on here