reinterpret segfault #21216
Comments
|
Seems to be an alignment issue for fp128. |
You mean alignment issue for |
|
I mean |
|
|
|
So it is a floating point type. |
|
Is it because |
Yes.
What do you mean "take that into account"? The main difference is likely that one is compiled and the other is not. |
JeffBezanson
added
kind:bug
|
Possibly related problem, observed on MacOS: julia> collect(v for i in 1:1, v in zeros(Dec64, 1))
1×1 Array{DecFP.Dec64,2}:
+0E+0
julia> collect(v for i in 1:1, v in zeros(Dec128, 1))
1×1 Array{DecFP.Dec128,2}:
+4639814192E-6176Something about accessing a 128-bit primitive type (formerly |
|
Here is a minimal example that exhibits the problem on MacOS, without requiring the DecFP module: julia> abstract type DecimalFloatingPoint <: AbstractFloat end
julia> primitive type Dec128 <: DecimalFloatingPoint 128 end
julia> collect(v for i in 1:1, v in [reinterpret(Dec128, UInt128(0))])
1×1 Array{Dec128,2}:
Dec128(0x000000011428beb0ffffffffffffffff)(The output varies, as you might expect: it is clearly reading memory it is not supposed to. @rdeits saw a segfault from the same code, so I think this is probably the same as originally reported above.) |
|
In Julia 0.5, there is a different error: abstract DecimalFloatingPoint <: AbstractFloat
bitstype 128 Dec128 <: DecimalFloatingPoint
collect(v for i in 1:1, v in [reinterpret(Dec128, UInt128(0))])gives |
|
@yuyichao, how can the 0.6 behavior be a dup of a closed issue? |
|
Because both are round trip reinterpret through a floating point type. |
|
It is a user-defined floating-point type that should be treated as just an opaque bitbucket, no different from Regarding the 0.5 issue, it goes away for |
|
User defined floating point primitive types are mapped to machine floating point types. You can use |
|
primitive types are special if they are |
|
We could consider changing this and introducing something like |
|
It's not clear to me how #18019 explains: | | |_| | | | (_| | | Version 0.6.0-pre.alpha.265 (2017-03-27 13:16 UTC)
_/ |\__'_|_|_|\__'_| | Commit f65b8aba9a (2 days old master)
|__/ | x86_64-apple-darwin13.4.0
julia> using DecFP
julia> x = zeros(Dec128, 1);
julia> collect(v for i in 1:1, v in x)
[1] 32448 segmentation fault julia-0.6 |
|
Julia exports
|
|
Re #18019 is about round trip bitcast. The segfault is related to alignment of fp128 as I mentioned in my very first comment.... |
|
Why can't we do |
|
Because primitive types aren't useful for what you're trying to do. The whole notion of |
|
If the whole notion is broken, why do we have them? |
|
Because we need some way to bootstrap. |
|
More fundamentally though, the only thing you can do with a primitive type is pass it to intrinsics. The fact that you can pass them to ccall at all is a bit of an accident, because the C ABI does very much care about the identity of a primitive type, not just how large it is. |
|
So they shouldn't be documented? Currently, the manual says:
To be honest, I find this much nicer than declaring Given that we document and export this feature, having it be broken for subtypes of |
|
Can't we just
? |
|
|
Thanks @Keno, that works, and I'll do that anyway since DecFP still supports 0.5. But I still would prefer something like my 3-step suggestion above, with the goal of making |
|
They aren't more convenient though. The fact that reinterpret works is mostly an accident. If you want to do anything with them you have to pass them to intrinsics. For convenience, a macro would do fine. |
|
I would like to think that all of the work I've put into defining the The question how they get aligned and laid out in a struct is a bit of a different matter. We have an explicit (although currently the parser doesn't read that correctly) |
|
Alignment isn't the only issue though. |
|
Yes, we could expand the primitive type definition to specify all the various properties (alignment, memory size, loaded size, kind (integer, floating point, double double, long fp)), but that's not what it does at the moment, and at the moment I can't think of any cases where a user can meaningfully use this. |
|
|
|
|
|
(i.e. it's not less portable than |
|
Just express it by |
|
I'm certain this can be made to do something other than segfault. Can we lower everything except the few special cases in the C ABI to llvm integer types? |
|
The representation issue unrelated to the segfault. We always need to have a type to represent fp128 and that type is currently having the wrong alignment. |
avoids casting away floating point bits until used in a floating-point operation also ensures that alignment is consistent in the LLVM struct representation as in the Julia struct representation computation fix #21216
avoids casting away floating point bits until used in a floating-point operation also ensures that alignment is consistent in the LLVM struct representation as in the Julia struct representation computation fix #21216
ensures that alignment is consistent in the LLVM struct representation as in the Julia struct representation computation also helps ensure that the floating point NaN payload bits won't accidentally get discarded for non-IEEE-754 subtypes of AbstractFloat fix #21216
ensures that alignment is consistent in the LLVM struct representation as in the Julia struct representation computation also helps ensure that the floating point NaN payload bits won't accidentally get discarded for non-IEEE-754 subtypes of AbstractFloat fix #21216
ensures that alignment is consistent in the LLVM struct representation as in the Julia struct representation computation also helps ensure that the floating point NaN payload bits won't accidentally get discarded for non-IEEE-754 subtypes of AbstractFloat fix JuliaLang#21216
ensures that alignment is consistent in the LLVM struct representation as in the Julia struct representation computation also helps ensure that the floating point NaN payload bits won't accidentally get discarded for non-IEEE-754 subtypes of AbstractFloat fix #21216 (cherry picked from commit ece60d0) ref #21425
ensures that alignment is consistent in the LLVM struct representation as in the Julia struct representation computation also helps ensure that the floating point NaN payload bits won't accidentally get discarded for non-IEEE-754 subtypes of AbstractFloat fix #21216 (cherry picked from commit ece60d0) ref #21425 resolve an ambiguity from the AbstractFloat codegen test type
ensures that alignment is consistent in the LLVM struct representation as in the Julia struct representation computation also helps ensure that the floating point NaN payload bits won't accidentally get discarded for non-IEEE-754 subtypes of AbstractFloat fix #21216 (cherry picked from commit ece60d0) ref #21425 resolve an ambiguity from the AbstractFloat codegen test type add 0 third argument to jl_subtype for release-0.5
The following behavior only seems to exist on linux current master (1dd10aa). Discovered in the DecFP.jl package (current master), travis logs here. Repro:
As far as I can tell,
reinterpret(UInt128, x)just callsBase.bitcast, so I'm not sure why one segfaults and the other seems to work just fine.The text was updated successfully, but these errors were encountered: