Test suite fails on macOS/Metal: Float64 reaching Metal arrays, KA-on-Metal allocators, and memopt metadata #217

Summary

Running Pkg.test() on an Apple-silicon Mac gives 35 failures/errors across 5 test files on main. The CPU backends are entirely green, every failure is on Metal, either directly (package: Metal) or through package: KernelAbstractions, whose backend resolves to Metal on this machine.

Environment

• Julia 1.12.6, macOS 26.6.2, Apple M2 (aarch64)
• ParallelStencil a0b76d2 (v0.16.0)
• Metal 1.9.3, KernelAbstractions 0.9.42, Enzyme 0.13.199, CellArrays 0.3.3
• No CUDA/ROCm device present

1. Bare Float64 literals promote Metal arrays to Float64 (4 errors)

test/test_FiniteDifferences3D.jl:118 multiplies by a literal 0.125, while every neighbouring line correctly uses $FloatDefault(0.5):

@test all(Array(R .== (Axyz[...] .+ ... .+ Axyz[...])*0.125))

With FloatDefault = Float32 on Metal, the Float64 literal promotes the broadcast result to Float64 and the allocation fails with Metal does not support Float64 values. Same class of issue at test/test_parallel.jl:1573-1574 (A3 == 2.0 .* @ones(4,5,2)).

Fix would be $FloatDefault(0.125) / $FloatDefault(2.0).

2. KernelAbstractions tests use Float64 although the KA backend is Metal (14 errors)

Every test file selects the number type by package symbol only:

FloatDefault = (package == PKG_METAL) ? Float32 : Float64

so package: KernelAbstractions gets Float64 even when @select_hardware(:gpu_metal) puts the KA backend on Metal. The Metal-only branches of the same files use Float16/Float32 and pass.

• test/ParallelKernel/test_allocators.jl:183,186,512,513: hardcoded eltype=Float64 inside the for symbol in valid_symbols loop, e.g.
  @test typeof(@rand(2,3, eltype=Float64)) == typeof(KernelAbstractions.allocate(backend_handle, Float64, 2, 3))
• test/ParallelKernel/test_hide_communication.jl:95,122,130,143,158,167,176,185,195,214

The number type (and the hardcoded Float64 eltypes) should follow the selected hardware, not the package symbol.

3. Enzyme AD passes a Float64 scalar into a Metal kernel (2 errors)

test/ParallelKernel/test_parallel.jl:261 and :275:

InvalidIRError: compiling MethodInstance for autodiff_deferred!(::ReverseMode{...},
  ::var"#f!#f!##5", ::DuplicatedNoNeed{MtlDeviceVector{Float32,1}},
  ::DuplicatedNoNeed{MtlDeviceVector{Float32,1}}, ::Const{Float64}, ...)
Reason: unsupported use of double value

The arrays are correctly Float32; the scalar argument stays Const{Float64}.

4. CellArray type mismatch under KernelAbstractions + :gpu_metal (10 failures)

test/ParallelKernel/test_allocators.jl:325-328, 446-447, 603-604, 703-704:

Expression: typeof(@rand(2,3, celldims=(3,4))) == typeof(MtlCellArray{T_Float16,0}(undef,2,3))
Evaluated:  CellArray{SMatrix{3,4,Float16,12}, 2, 1, MtlArray{Float16,3,PrivateStorage}} ==
            CellArray{SMatrix{3,4,Float16,12}, 2, 0, MtlArray{Float16,3}}

Two differences: blocklength 1 vs 0, and the fully parameterised storage type. The equivalent tests under package: Metal pass (test_allocators is 409/409 there), so it is specific to what the KA path allocates. Unclear to me whether the allocator or the test reference is wrong.

5. memopt metadata differs on Metal (5 failures)

test/test_parallel.jl:1487-1491, in the @static if @isgpu($package) branch, for

@parallel_indices (ix, iy, iz) memopt=true loopsize=3 optvars=B function metadata_memopt_fullstencil_probe!(A, B, D)
    A[ix, iy, iz] = B[ix-1, iy-1, iz-1] + B[ix, iy, iz] + B[ix+1, iy+1, iz+1] + D[ix, iy, iz, 1]

metadata_full.stencilranges  → (B = (0:0, 0:0, 0:0),)   expected (B = (-1:1, -1:1, -1:1),)
metadata_full.shmem_spans    → (B = (0, 0),)            expected (B = (2, 2),)
metadata_full.shmem_optvars  → ()                       expected (:B,)
metadata_full.use_any_shmem  → false                    expected true

The full 3-D stencil is detected as having no extent, so no shared memory is used. This is the one group that is not explained by Float64. define_optranges (src/memopt.jl:675) branches on get_compute_capability(package), which may be the reason the GPU expectations written for CUDA/AMDGPU do not hold on Metal.

Secondary obs

but a failing package aborts the remaining packages in that file. ParallelKernel/test_parallel.jl, test_parallel.jl and test_FiniteDifferences3D.jl never emit a package: KernelAbstractions summary at all, even though KA is in TEST_PACKAGES (it is only filtered when KernelAbstractions.functional(CPU()) is false, and it does run in other
files). In all three, Metal failed as it precedes KA in SUPPORTED_PACKAGES; in the two files where Metal passed, KA did run. So a failure in one package's testset appears to abort the @static for package in TEST_PACKAGES loop, silently skipping every later package.