> Those numbers look like pointers interpreted as fixnums
Yes.
The optimizer thought that the result of (bitwise-and num -2) was a
fixnum, so it changed
(bitwise-ior (bitwise-and num -2) 0)
to
(unsafe-fxior (bitwise-and num -2) 0)
All the pointers are even (actually a multiple of 4 in 32 bi
Those numbers look like pointers interpreted as fixnums.
So my guess as to why they differ so much is that between each
operation, you call `printf`, which allocates enough to claim the
addresses between, e.g., 70112357026588 and 70112357038692. So that next
time around the loop, the result of the
Do you have any guess why the resulting numbers vary so much?
On Thursday, October 13, 2016 at 7:20:47 PM UTC+2, mflatt wrote:
>
> Thanks for the report!
>
> This is a bug in the optimizer's handling of `bitwise-and`, where I
> made it assume a fixnum result if either argument is a fixnum. That'
Thanks for the report!
This is a bug in the optimizer's handling of `bitwise-and`, where I
made it assume a fixnum result if either argument is a fixnum. That's
obviously not correct if the fixnum is negative. I'll push a repair.
The difference you see when running in a module is because the
opt
I can confirm weird behavior (and I get different weird results):
Welcome to Racket v6.5.
> (define num #x)
(for ([i 5])
(printf "~a~n" (bitwise-ior (bitwise-and num -2) 0)))
2192618128
2192618180
2192618200
2192618668
2192618688
> (for ([i 5])
(printf "~a~n" (bitwise-ior (bitw
Hi all,
I get a weird behavior when using bitwise-ior and bitwise-and with large
numbers. Tested on 2 machines (racket 6.6, Ubuntu 16.04 and 14.04):
Here is the test example:
#lang racket
(define num #x) ;; remove one f, and the results are fine
in both cases
(for ([i 5])
(pr