-
Notifications
You must be signed in to change notification settings - Fork 149
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SVector
type unstable for Julia v1.9 and --check-bounds=no
#1155
Comments
using Cthulhu with remarks, and effects on. Check-bounds=0
Check-bounds=auto
|
The failure comes from:
Check-bounds=0
Check-bounds=auto
|
cc: @aviatesk Noteworthy difference is:
|
This was referenced Apr 24, 2023
This was referenced May 13, 2023
aviatesk
added a commit
to JuliaLang/julia
that referenced
this issue
Jun 8, 2023
From version 1.9 onwards, when `--check-bounds=no` is used, concrete-eval is completely disabled. However, it appears `--check-bounds=no` is still being used within the community, causing issues like the one reported in JuliaArrays/StaticArrays.jl#1155. Although we should move forward to a direction of eliminating the flag in the future (#48245), for the time being, there are many requests to carry out a certain level of compiler optimization, even when this flag is enabled. This commit aims to allow concrete-eval "safely" even under `--check-bounds=no`. Specifically, when the method call being analyzed is `:nothrow`, it should be predominantly safe to concrete-eval it under this flag. Technically, however, even `:nothrow` methods could trigger undefined behavior, since `:nothrow` isn't a strict constraint and it's possible for users to annotate potentially risky methods with `Base.@assume_effects :nothrow`. Nonetheless, since this possibility is acknowledged in `Base.@assume_effects` documentation, I feel it's fair to relegate it to user responsibility.
vchuravy
pushed a commit
to JuliaLang/julia
that referenced
this issue
Jun 12, 2023
#50107) From version 1.9 onwards, when `--check-bounds=no` is used, concrete-eval is completely disabled. However, it appears `--check-bounds=no` is still being used within the community, causing issues like the one reported in JuliaArrays/StaticArrays.jl#1155. Although we should move forward to a direction of eliminating the flag in the future (#48245), for the time being, there are many requests to carry out a certain level of compiler optimization, even when this flag is enabled. This commit aims to allow concrete-eval "safely" even under `--check-bounds=no`. Specifically, when the method call being analyzed is `:nothrow`, it should be predominantly safe to concrete-eval it under this flag. Technically, however, even `:nothrow` methods could trigger undefined behavior, since `:nothrow` isn't a strict constraint and it's possible for users to annotate potentially risky methods with `Base.@assume_effects :nothrow`. Nonetheless, since this possibility is acknowledged in `Base.@assume_effects` documentation, I feel it's fair to relegate it to user responsibility.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As described in JuliaLang/julia#49472, using StaticArrays.jl with Julia v1.9 and
--check-bounds=no
causes theSVector
constructor to be type unstable even for the simplest invocations.To reproduce, start Julia v1.9 (RC1 or later were tested and reproduce this problem) with
--check-bounds=no
and then run the following:Without
--check-bounds=no
, we get the expected, type stable output:This regression renders StaticArrays.jl virtually unusable with Julia v1.9 for many HPC workloads (hot kernels that make generous use of
SVector
basically grind to a halt). In the linked julia issue above it was hinted that this is not going to be fixed in Julia base, and @vchuravy suggested that I should rather file an issue here (keeping fingers crossed 🙏).cc @ranocha
The text was updated successfully, but these errors were encountered: