Strange code generation with unsafe_trunc and dynamic dispatch
#54264
Comments
KristofferC
changed the title
unsafe_trunc/reinterpret with dynamic dispatchunsafe_trunc/reinterpret with dynamic dispatch on 1.6
|
Without doing any analyzing it seems that the results are consistent on 1.7 at least. |
|
However, as mentioned above, this type of problem seems to be occurring even on v1.10.2. |
KristofferC
changed the title
unsafe_trunc/reinterpret with dynamic dispatch on 1.6unsafe_trunc/reinterpret with dynamic dispatch
|
Although the following depends on ColorTypes and FixedPointNumbers, it reproduces the problem on Julia v1.10.2. (This is close to the actual code implemented in ColorTypes) using ColorTypes # v0.11.5
using FixedPointNumbers # v0.8.4
function n0f8(x)
reinterpret(N0f8, unsafe_trunc(UInt8, unsafe_trunc(Int8, x * 255.0f0)))
end
function agray32(val::Real, alpha=1)
AGray32(n0f8(val), n0f8(alpha))
end
function agray32(g::Gray24, alpha=1)
reinterpret(AGray32, UInt32(reinterpret(n0f8(alpha))) << 24 | g.color)
end
agray32(g::AbstractGray, alpha=1) = agray32(gray(g), alpha)
# The length of the Tuple (or the variety of types) affects the results.
for v in (N0f8(0.2), N0f16(0.2), Gray{N0f8}(0.2), Gray24(0.2))
println(agray32(v, 0.8))
endjulia> for v in (N0f8(0.2), N0f16(0.2), Gray{N0f8}(0.2), Gray24(0.2))
println(agray32(v, 0.8))
end
AGray32(0.2N0f8,0.8N0f8)
AGray32(0.2N0f8,0.8N0f8)
AGray32(0.2N0f8,0.8N0f8)
AGray32(0.2N0f8,0.0N0f8)
julia> agray32(Gray24(0.2), 0.8)
AGray32(0.2N0f8,0.8N0f8)
julia> versioninfo()
Julia Version 1.10.2
Commit bd47eca2c8 (2024-03-01 10:14 UTC)
Build Info:
Official https://julialang.org/ release
Platform Info:
OS: Windows (x86_64-w64-mingw32)
CPU: 8 × 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
WORD_SIZE: 64
LIBM: libopenlibm
LLVM: libLLVM-15.0.7 (ORCJIT, tigerlake)
Threads: 1 default, 0 interactive, 1 GC (on 8 virtual cores)Not tested for v1.10.3. |
|
v1.12.0-DEV is fine or robust enough. julia> for v in (N0f8(0.2), N0f16(0.2), Gray{N0f8}(0.2), Gray24(0.2))
println(agray32(v, 0.8))
end
AGray32(0.2N0f8, 0.8N0f8)
AGray32(0.2N0f8, 0.8N0f8)
AGray32(0.2N0f8, 0.8N0f8)
AGray32(0.2N0f8, 0.8N0f8)
julia> versioninfo()
Julia Version 1.12.0-DEV.391
Commit 715c476d6a (2024-04-23 08:12 UTC)
Build Info:
Official https://julialang.org/ release
Platform Info:
OS: Windows (x86_64-w64-mingw32)
CPU: 8 × 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
WORD_SIZE: 64
LLVM: libLLVM-16.0.6 (ORCJIT, tigerlake)
Threads: 1 default, 0 interactive, 1 GC (on 8 virtual cores) |
|
@Keno do you want to add this function to your UB document, or do we need to remove it from the consistent list for functions? (I am strongly inclined to remove all float intrinsics from that list indeed) |
|
What specifically is the issue here? |
|
I recognize that this is more a problem of unintuitive behavior as a result of |
|
I think there should be more supplemental documentation for Edit: xref: #54297 |
kimikage
changed the title
unsafe_trunc/reinterpret with dynamic dispatchunsafe_trunc and dynamic dispatch
|
I removed |
Needs to be removed from the consistent list along with the other floating point intrinsics (#49353). |
|
Would you close this as a common issue regarding I intend to fix (mitigate) the Or do we analyze this strange behavior and work to reduce the risk of potential bugs emerging? |
|
|
|
Yes, I think this is a problem with "poison value" in the context of LLVM. However, I don't think the term "poison value" is defined in Julia documentation. |
|
No, it's no a poison value, we freeze it. It's just what the documentation says. An arbitrary (possibly different on every invocation) value of the specified type. |
|
I think you are definitively right. |
|
Just to confirm, there is no motivation at this time to specialize for small types like This is not a |
|
This is not directly related to UB. |
Uh oh!
There was an error while loading. Please reload this page.
This is a bug that was originally found in ColorTypes.jl, the 32-bit color constructors.(cf. JuliaGraphics/ColorTypes.jl#288)
However, this does not appear to be a problem specific to ColorTypes.jl or FixedPointNumbers.jl.
Also, this problem is indirectly caused by workaround for ARM's
unsafe_trunc, but it also occurs on x64.The following MWE reproduces the problem with Julia v1.6.7.
It appears that the same type of problem occurs with Julia v1.10.2, although I have not succeeded in creating the MWE. (cf: #54264 (comment))
ColorTypes v0.11.5 CI test log with julia v1.10.2 (aarch64 with QEMU)
So far, this problem has not been observed on the nightly build (v1.12.0-DEV).
I have not been able to identify the cause, so the issue title may be misleading.
Note that I suspect this is a constant propagation problem, but I am not certain. I think the behavior of
unsafe_truncdiffers between the runtime native code and the constant propagation.Edit: Of course, if you specify a value such as
0.4instead of0.8, it is definitely safe to truncate.The text was updated successfully, but these errors were encountered: