JuliaSIMD / JuliaSIMD/LoopVectorization.jl
`@turbo` behavior change in Julia v1.11: bounds check triggered when using `indices`
- Lenguaje dominante
- Julia
- Estrellas
- 789
- Forks
- 73
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Descripción
Dear all,
In **Julia v1.10**, the following function using `@turbo` from **LoopVectorization.jl** runs without error and returns `10`:
```julia
using LoopVectorization
a = ones(10)
b = ones(11)
@inline function dot(A::AbstractArray{T}, B::AbstractArray{T}) where {T}
ret = zero(T)
@turbo for m ∈ indices((A, B), 1)
ret += A[m] * B[m]
end
ret
end
dot(a, b) # returns 10 in Julia v1.10
```
However, in **Julia v1.11**, the same code results in the following error:
```
ERROR: 10 and 11 are not equal.
```
This seems to stem from a bounds check triggered deep inside the `_static_promote` function from [Static.jl](https://github.com/SciML/Static.jl/blob/master/src/Static.jl#L326), likely when evaluating `indices((A, B), 1)` together with `@turbo`.
---
## Question
- Is this change **intentional** (i.e., a **feature**) or a **bug**?
- In previous versions, `@turbo` appeared to skip such bounds checks and worked leniently over the shortest matching dimension.
- In Julia v1.11, this stricter behavior is triggered — perhaps correctly — but it may break previous code that relied on implicit truncation via `indices`.
If this is intended, should users now explicitly write:
```julia
for m in 1:min(length(A), length(B))
```
While the bounds check may lead to more robust behavior, it also breaks backwards compatibility with earlier versions where this function ran fine.
I'd appreciate any clarification on whether this is expected behavior or if it indicates a bug in `@turbo` or a related change in how `indices` behaves with StaticArrays.
Thanks in advance!
Guía de contribución
No hay ninguna guía de contribución indexada para este repositorio
Línea de trabajo
Reproduce el ejemplo con Julia v1.10 y v1.11 usando LoopVectorization.jl, centrándote en @turbo con indices((A, B), 1). Lee la implementación vinculada de _static_promote en Static.jl y determina si la comprobación de límites es intencionada; se considera terminado cuando se haya aclarado el cambio de compatibilidad o se haya identificado una regresión en el comportamiento informado.
Escrito por el modelo de indexación a partir del texto del issue.
Evaluación
- Stack tecnológico
- julia
- Área
- performance
- Tipo de issue
- Error
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Estado de actividad
- Estancado
- Claridad
- Bastante claro
- Aptitud para principiantes
- 35/100