Julia: Boundschecking test failure in arrayops

Created on 8 May 2018  路  8Comments  路  Source: JuliaLang/julia

At some point in the past 4 days (429a885e74 is a known good commit), the following failure was introduced:

julia> rand(4, 3, 2)[Base.OneTo(4), Base.OneTo(3), [2]]
ERROR: BoundsError: attempt to access 4脳3脳2 Array{Float64,3} at index [Base.OneTo(4), Base.OneTo(3), [2]]
Stacktrace:
 [1] throw_boundserror(::Array{Float64,3}, ::Tuple{Base.OneTo{Int64},Base.OneTo{Int64},Array{Int64,1}}) at ./abstractarray.jl:480
 [2] checkbounds at ./abstractarray.jl:445 [inlined]
 [3] _getindex at ./multidimensional.jl:622 [inlined]
 [4] getindex(::Array{Float64,3}, ::Base.OneTo{Int64}, ::Base.OneTo{Int64}, ::Array{Int64,1}) at ./abstractarray.jl:958
 [5] top-level scope

This is a strange one, because:

  • It only fails when called from global (or type-unstable) scopes
  • It's actually tested in test/arrayops.jl, but for some reason CI hasn't caught it. Perhaps this is a CPU-dependent thing? My system is:
julia> versioninfo()
Julia Version 0.7.0-DEV.5046
Commit c8d46146f5 (2018-05-08 16:15 UTC)
Platform Info:
  OS: Linux (x86_64-linux-gnu)
  CPU: Intel(R) Xeon(R) Silver 4114 CPU @ 2.20GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-6.0.0 (ORCJIT, skylake)
Environment:

I'm suspecting the LLVM upgrade here, but I've not tried bisecting yet. Bisected to SLP optimizer bf29b402f6e07a52851c771917820f3c2af2bc89 (https://github.com/JuliaLang/julia/pull/26594).

bug codegen upstream

Most helpful comment

All 8 comments

I've seen this failure (well, a failure like this) on #27022 and it's really mysterious. I thought I had messed something up there. Where I stopped debugging was the following:

function foo(A::AbstractArray, I::Vararg{Any,N}) where {N}
    @Base._inline_meta
    X = (13, 6, [1]);
    #Y = X === Base.to_indices(A, I); <-- Uncomment this line to introduce failure on the next line
    @boundscheck checkbounds(A, X...)
    ccall(:jl_, Cvoid, (Any,), Y)
end
foo(rand(13, 13, 13), 13, 6, [1])

which is really strange because obviously that shouldn't change anything. I also suspect some optimization is going wrong somewhere

First bad commit is bf29b402f6e07a52851c771917820f3c2af2bc89 (https://github.com/JuliaLang/julia/pull/26594).

Did it also fail pre that commit with -O3 then?

Yes, dde401e869 (immediately preceding the first bad commit) also fails with -O3. The build that I have that's still on LLVM 3.9.2 (429a885) works with -O3.

Valentin reports that he doesn't see this failure on

julia> versioninfo()
Julia Version 0.7.0-DEV.5038
Commit 1feb5059f8* (2018-05-07 21:45 UTC)
Platform Info:
  OS: Linux (x86_64-pc-linux-gnu)
  CPU: Intel(R) Core(TM) i7-7660U CPU @ 2.50GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-6.0.0 (ORCJIT, skylake)

This is a bug in LLVM's AVX512 codegen. Trying to come up with a simple IR reproducer.

Was this page helpful?
0 / 5 - 0 ratings