WIP: checked integer conversions #8420
Conversation
…> T (#3759) the sysimg builds, but still need to: - check same-size signed<->unsigned conversion - make tests pass
this would be a bit cleaner without the code in intfuncs that dispatches on Unsigned. signed() and unsigned() are convenient for testing bit patterns in the test suite. for now replace with assigned() and asunsigned(). uint8(x) is convenient for moving bytes around, so it remains unchecked. we should perhaps rename this to byte(), and either eliminate uint8() entirely, or make it checked.
…nt_trunc Conflicts: base/number.jl
|
|
||
| ## integer arithmetic ## | ||
| +(x::Int, y::Int) = box(Int,add_int(unbox(Int,x),unbox(Int,y))) |
There was a problem hiding this comment.
isn't this a duplicate of one of the definitions in the for eval loop below?
There was a problem hiding this comment.
Yes but I believe it is needed to be able to execute the for loop.
|
Seems to include #8028. |
|
@JeffBezanson, you also need to fix these. EDIT: also here, and I think quite a few other places in As I pointed out #8028 (comment), this change in behavior may not be caught by many tests. So I suspect the fact that (1) "did not break much" may not tell the whole story. I for one am sure I have a lot of code where I add small integers together, and now probably need to throw in a few To be clear, I completely support & endorse this change, but realistically I think this will be one of the most painful transitions in 0.4. |
|
@IainNZ, once merger seems imminent (and I think this is very close to ready) this would be a good PR to prospectively run through PackageEval. |
|
I can certainly do that if it'd be helpful |
…nt_trunc Conflicts: base/intfuncs.jl
a few fixes in base for the convert and arithmetic changes get all tests passing
type-preserving arithmetic.
allow reducedim(+, A, 2), which previously gave
```
ERROR: `reducedim_init` has no method matching reducedim_init(::IdFun, ::Function, ::Array{Uint8,2}, ::Int64)
in reducedim at reducedim.jl:217
```
|
I believe this is done now. |
|
I'm still a little worried about Of course, some of those optimizations might be rolled back anyway, in light of the recent SIMD advances. It would be nice to have it be simpler... |
|
I'm also concerned about reductions producing the same type. I feel like reductions over small types should produce Int/Uint. |
|
Many failures, but hopefully mostly from JSON.jl: http://pkg.julialang.org/pulse.html You can click on the test status of a package on that pulse page to take you to the entry for that package, where you can view the log. |
|
The JSON issue appears to be happening because it uses a Char range that starts with |
|
See #8524 |
|
32-bit Fedora 19 Linux build is broken. hashing.jl On 9/29/14, Tony Kelman [email protected] wrote:
|
|
32-bit windows build also broken (LLVM 3.3) ,but 64-bit windows build ok |
|
32-bit Fedora 19 Linux build broken in bootstrap with |
|
This is shaping up to be a real 0.4 change 😉. |
I also got rid of the manual inlining since the compiler now appears to inline everything on its own. Fixes #6. Ref JuliaLang/julia#8539
This is not done yet but ready for discussion at least.
converttruncates integers #5413, checking integer truncations(1) was simple and did not really break much.
(2) was a bit more breaking, but not too bad and leads to clearer code in most cases.
(3) was kind of a disaster and seems to be very annoying.
The problem with (3) is that interpreting a 2's complement integer as unsigned is mathematically useful. It also comes up a lot in hashing, random number generation, and when you just want to write a byte to an IO stream.
I'm not sure yet how to rewrite
julia/base/random.jl
Line 209 in ec607da
I think adding these checks is clearly the right thing, but I was surprised at how many legitimate uses of "unsafe" integer conversion there were. I added methods to
itruncfor unsafely truncating integers, but this only handles converting from larger to smaller. We need to figure out what other functions might be needed.