prevent conj! into uninitialized memory

[KristofferC]

From my understanding, the current matmul code loads some buffer memory and "casts" it to an array of the element type:

julia/stdlib/LinearAlgebra/src/matmul.jl

Line 833 in 2fed7c3

Btile = unsafe_wrap(Array, convert(Ptr{S}, pointer(Bbuf[Threads.threadid()])), sz)

stores some data into a part of that buffer:

julia/stdlib/LinearAlgebra/src/matmul.jl

Line 840 in 2fed7c3

copyto!(Btile, 1:mB, 1:nB, tB, B, 1:mB, 1:nB)

, but then goes on and conj! the full memory:

julia/stdlib/LinearAlgebra/src/matmul.jl

Line 686 in 2fed7c3

tM == 'C' && conj!(B)

Since this code runs for user defined types calling conj on uninitialized memory can have side effects (like throwing). I think this is what causes the errors in https://s3.amazonaws.com/julialang-reports/nanosoldier/pkgeval/by_hash/f2bc4d3_vs_9283b6c/NiceNumbers.1.6.1-pre-d190257cce.log. Tests passes with this PR.

Im not 100% sure my analysis here is correct so some more eyes on it would be nice.

[KristofferC]

This seems to come from f597671 (9 years ago!),

julia/base/linalg_dense.jl

Line 30 in f597671

conj!(B)

so @timholy, any comments? :P

[Sacha0]

Nice catch! Seems correct to me. Not sure what performance implications might be. Thanks Kristoffer! :)

[mbauman]

Yep, seems right to me. We limit this buffer use to bitstypes, and most bitstypes will happily conj over their entire possible bitsrepresentation domain unless someone gets real unlucky with a typemin(Int) value in a rational... or you have a fancier datatype that needs to do more computation on conj/construction like NiceNumbers. Simple REPL testing:

julia> struct BrokenInt <: Number
           i::Int
       end

julia> Base.:*(::BrokenInt, ::BrokenInt) = BrokenInt(42)

julia> Base.:+(::BrokenInt, ::BrokenInt) = BrokenInt(42)

julia> Base.zero(::BrokenInt) = BrokenInt(0)

julia> Base.conj(b::BrokenInt) = b.i == 42 ? b : error()

julia> fill(BrokenInt(42), 10,100)' * fill(BrokenInt(42), 100,10)'
ERROR:
Stacktrace:
  [1] error()
    @ Base ./error.jl:42
  [2] conj
    @ ./REPL[5]:1 [inlined]

Your patch fixes it.

[KristofferC]

I'll add that as a test!

[KristofferC]

The test caused some ambiguities so removed it for now. I'll open another PR with it.

[fkastner]

Thanks!
This is the conclusion I came to, too: #39708.
Now I can close that issue.

[KristofferC]

Oops, totally missed that issue.