[maleadt]

Since #570 stores oneArray offsets in bytes, reinterpret of a view can produce an array that isn't aligned for its element type. Copying such an array works, but kernels assume the element type's alignment, and on Intel GPUs they then access the wrong memory without any error. On an Arc A770:

julia> d = oneArray(UInt8.(0:63));
julia> v = reinterpret(UInt64, view(d, 2:17));   # starts at byte 1
julia> v .= v .+ 1;
julia> findall(Array(d) .!= 0:63) .- 1           # expected bytes 1 and 9 to change
Int64[]
julia> Array(v .+ 0x0)                           # reads bytes 0-15 instead of 1-16
2-element Vector{UInt64}:
 0x0706050403020100
 0x0f0e0d0c0b0a0908

This PR checks the pointer when a oneArray is converted to a device array, both when launching a kernel and in unsafe_convert, and throws an ArgumentError that suggests copy. Empty arrays are exempt. The check uses the alignment that device-side element accesses already assume, so nothing that currently works correctly is rejected. A device-side reinterpret to a type with a stronger alignment requirement (e.g. Int32 to Int64) checks the pointer as well. That required fixing device-side reinterpret first: it called an undefined _reinterpret_exception, so every kernel using it failed to compile (separate commit).

CUDA.jl makes the same change. On NVIDIA GPUs these kernels fault with ERROR_MISALIGNED_ADDRESS and leave the context unusable (x-ref JuliaGPU/CUDA.jl#3451). Raising the assumed alignment to the element size so that ComplexF32 or NTuple{4,Float32} get vector loads, as CUDA.jl also does, isn't worth it here: IGC already emits d32x2/d32x4 loads for those types on the A770, and the generated code and timings were identical with the higher alignment.

Tested on an Arc A770 by running array and execution. With the new tests but without the fix, the broadcast and unsafe_convert tests don't throw, and the device-side reinterpret reads 0x0000000200000000 instead of not storing.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.64%. Comparing base (584af0b) to head (de005dc).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #733      +/-   ##
==========================================
- Coverage   86.93%   86.64%   -0.30%     
==========================================
  Files          56       55       -1     
  Lines        5120     4993     -127     
==========================================
- Hits         4451     4326     -125     
+ Misses        669      667       -2     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.