Convert hpmv input to a BlasInt.

[maleadt]

Fixes failure seen on Aarch64:

Worker 3 failed running test LinearAlgebra/blas:
Some tests did not pass: 628 passed, 0 failed, 2 errored, 0 broken.
LinearAlgebra/blas: Error During Test at /tmp/julia-fd7eaca115/share/julia/stdlib/v1.5/LinearAlgebra/test/blas.jl:206
  Got exception outside of a @test
  MethodError: no method matching hpmv!(::Char, ::Int64, ::Complex{Float32}, ::Array{Complex{Float32},1}, ::Ptr{Complex{Float32}}, ::Int32, ::Complex{Float32}, ::Ptr{Complex{Float32}}, ::Int32)
  Closest candidates are:
    hpmv!(::AbstractChar, !Matched::Int32, ::Complex{Float32}, ::Union{Ptr{Complex{Float32}}, AbstractArray{Complex{Float32},N} where N}, ::Union{Ptr{Complex{Float32}}, AbstractArray{Complex{Float32},N} where N}, ::Integer, ::Complex{Float32}, ::Union{Ptr{Complex{Float32}}, AbstractArray{Complex{Float32},N} where N}, ::Integer) at /buildworker/worker/package_linuxaarch64/build/usr/share/julia/stdlib/v1.5/LinearAlgebra/src/blas.jl:849
    hpmv!(::AbstractChar, !Matched::Int32, !Matched::Complex{Float64}, !Matched::Union{Ptr{Complex{Float64}}, AbstractArray{Complex{Float64},N} where N}, !Matched::Union{Ptr{Complex{Float64}}, AbstractArray{Complex{Float64},N} where N}, ::Integer, !Matched::Complex{Float64}, !Matched::Union{Ptr{Complex{Float64}}, AbstractArray{Complex{Float64},N} where N}, ::Integer) at /buildworker/worker/package_linuxaarch64/build/usr/share/julia/stdlib/v1.5/LinearAlgebra/src/blas.jl:849
    hpmv!(::AbstractChar, ::Number, !Matched::Union{AbstractArray{T,1}, DenseArray{T,N} where N}, ::Union{AbstractArray{T,1}, DenseArray{T,N} where N}, !Matched::Number, !Matched::Union{AbstractArray{T,1}, DenseArray{T,N} where N}) where T<:Union{Complex{Float32}, Complex{Float64}} at /buildworker/worker/package_linuxaarch64/build/usr/share/julia/stdlib/v1.5/LinearAlgebra/src/blas.jl:875
  Stacktrace:
   [1] macro expansion at ./gcutils.jl:96 [inlined]
   [2] hpmv!(::Char, ::Complex{Float32}, ::Array{Complex{Float32},1}, ::Array{Complex{Float32},1}, ::Complex{Float32}, ::Array{Complex{Float32},1}) at /buildworker/worker/package_linuxaarch64/build/usr/share/julia/stdlib/v1.5/LinearAlgebra/src/blas.jl:883
   [3] top-level scope at /tmp/julia-fd7eaca115/share/julia/stdlib/v1.5/LinearAlgebra/test/blas.jl:227
   [4] top-level scope at /buildworker/worker/package_linuxaarch64/build/usr/share/julia/stdlib/v1.5/Test/src/Test.jl:1116
   [5] top-level scope at /tmp/julia-fd7eaca115/share/julia/stdlib/v1.5/LinearAlgebra/test/blas.jl:209
   [6] top-level scope at /buildworker/worker/package_linuxaarch64/build/usr/share/julia/stdlib/v1.5/Test/src/Test.jl:1189
   [7] include(::Module, ::String) at ./Base.jl:377
   [8] include at /tmp/julia-fd7eaca115/share/julia/test/testdefs.jl:13 [inlined]
   [9] macro expansion at /tmp/julia-fd7eaca115/share/julia/test/testdefs.jl:25 [inlined]
   [10] macro expansion at /buildworker/worker/package_linuxaarch64/build/usr/share/julia/stdlib/v1.5/Test/src/Test.jl:1116 [inlined]
   [11] macro expansion at /tmp/julia-fd7eaca115/share/julia/test/testdefs.jl:24 [inlined]
   [12] macro expansion at ./util.jl:311 [inlined]
   [13] top-level scope at /tmp/julia-fd7eaca115/share/julia/test/testdefs.jl:22
   [14] eval at ./boot.jl:331 [inlined]
   [15] runtests(::String, ::String, ::Bool; seed::UInt128) at /tmp/julia-fd7eaca115/share/julia/test/testdefs.jl:28
   [16] (::Distributed.var"#104#106"{Distributed.CallMsg{:call_fetch}})() at /buildworker/worker/package_linuxaarch64/build/usr/share/julia/stdlib/v1.5/Distributed/src/process_messages.jl:294
   [17] run_work_thunk(::Distributed.var"#104#106"{Distributed.CallMsg{:call_fetch}}, ::Bool) at /buildworker/worker/package_linuxaarch64/build/usr/share/julia/stdlib/v1.5/Distributed/src/process_messages.jl:79
   [18] macro expansion at /buildworker/worker/package_linuxaarch64/build/usr/share/julia/stdlib/v1.5/Distributed/src/process_messages.jl:294 [inlined]
   [19] (::Distributed.var"#103#105"{Distributed.CallMsg{:call_fetch},Distributed.MsgHeader,Sockets.TCPSocket})() at ./task.jl:358

Ref #34211 (cc @ iolaszlo)

[dkarrasch]

Seems like those failures remained hidden behind download issues at the time. PR makes perfectly sense.

@iolaszlo We need to take this into account in the spmv PR.

[iolaszlo]

Seems like those failures remained hidden behind download issues at the time. PR makes perfectly sense.

@iolaszlo We need to take this into account in the spmv PR.

Thanks that's good to know. I used the n::BlasInt type in the lowest-level-longest-header wrapper of the fortran BLAS API for hpmv!. A pattern similar to the unpatched version of this code can be seen for example in axpy! the only difference being that there the lowest-level-longest-header wrapper contains not BlasInt but rather Integer. I wonder whether this is the crucial difference that makes relevant tests pass or fail....

[iolaszlo]

@dkarrasch As a note to my previous comment, it seems a bit confusing that automatic conversion from Integer to BlasInt does not work, whereas the case of converting from Integer to Ref{BlasInt} seems to be okay on the ccall level. (see for example axpy!)

[iolaszlo]

@dkarrasch I understand that on machines that do not use BLAS64 the type of BlasInt is Int32 to which Int64 is of course not a subtype, thus the current fix is needed.

Still it makes me think whether under the conditions BlasInt=Int32 and typeof(N) = Int64 <: Integer, passing an N larger than typemax(Int32) to axpy! would amount to some strange behaviour when conversion to Ref{BlasInt} during the ccall happens.

[dkarrasch]

Ok, so I took a more careful look at the types in the other BLAS functions, and it seems to me we have applied a fix in the "wrong" direction, as @iolaszlo indicated in #34360 (comment). Rather than converting to BlasInt, we should "relax" the low-level signature to Integers, as in the axpy! example. We should probably fix that in a separate PR after we have identified the correct overall pattern in #34320 for spmv!.