Summary
"maze" benchmark produces incorrect result when compiled wirth -block on x86-64
Metadata
- Id: b91c394d181c9280399ffe2a207db6a35c311876
- Trac id: 64
- Type: defect
- Reporter: felix
- Owner:
- Cc: mario
- Status: closed
- Component: core libraries
- Estimated difficulty:
- Resolution: fixed
- Priority: critical
- Milestone:
- Version: 4.1.x
- Changetime: 2009-12-01 16:01:13 UTC
- Created: 2009-08-06 09:06:44 UTC
- Keywords:
Description
(reported by mario)
Some initial testing by adding debugging output to `bit-test` indicates a bit-twiddling problem.
Changes and comments
[2009-08-06 10:12:26 UTC] felix wrote:
Adding this patch to `maze.scm`:
felix@frohike% diff -u benchmarks/maze.scm maze2.scm ~/chicken-4.1.0
--- benchmarks/maze.scm 2009-08-04 10:03:07.000000000 +0200
+++ maze2.scm 2009-08-06 10:11:48.000000000 +0200
@@ -646,7 +646,9 @@
(write-ch #\newline))))
(define (bit-test j bit)
- (not (zero? (bitwise-and j bit))))
+ (let ((n (not (zero? (bitwise-and j bit)))))
+ (print "bit-test: " j " " bit " -> " n)
+ n))
;;; Return a . if harr[r,c] is marked, otherwise a space.
;;; We use the dot to mark the solution path.
produces this diff:
felix@frohike% diff -u out1 out2|less ~/chicken-4.1.0 --- out1 2009-08-06 10:12:21.000000000 +0200 +++ out2 2009-08-06 10:12:26.000000000 +0200 @@ -1196,9 +1196,9 @@ bit-test: -1 1 -> #t bit-test: -1 2 -> #t bit-test: -1 4 -> #t -bit-test: 4611686018427387901 1 -> #t -bit-test: 4611686018427387901 2 -> #f -bit-test: 4611686018427387901 4 -> #t +bit-test: 0 1 -> #f +bit-test: 0 2 -> #f +bit-test: 0 4 -> #f bit-test: -1 1 -> #t bit-test: -1 2 -> #t bit-test: -1 4 -> #t @@ -2403,9 +2403,9 @@ bit-test: -1 1 -> #t bit-test: -1 2 -> #t bit-test: -1 4 -> #t -bit-test: 4611686018427387901 1 -> #t -bit-test: 4611686018427387901 2 -> #f -bit-test: 4611686018427387901 4 -> #t +bit-test: 0 1 -> #f +bit-test: 0 2 -> #f +bit-test: 0 4 -> #f bit-test: -1 1 -> #t bit-test: -1 2 -> #t bit-test: -1 4 -> #t @@ -3610,9 +3610,9 @@ bit-test: -1 1 -> #t bit-test: -1 2 -> #t bit-test: -1 4 -> #t -bit-test: 4611686018427387901 1 -> #t -bit-test: 4611686018427387901 2 -> #f -bit-test: 4611686018427387901 4 -> #t +bit-test: 0 1 -> #f +bit-test: 0 2 -> #f +bit-test: 0 4 -> #f bit-test: -1 1 -> #t bit-test: -1 2 -> #t bit-test: -1 4 -> #t @@ -4817,9 +4817,9 @@ bit-test: -1 1 -> #t bit-test: -1 2 -> #t bit-test: -1 4 -> #t -bit-test: 4611686018427387901 1 -> #t -bit-test: 4611686018427387901 2 -> #f -bit-test: 4611686018427387901 4 -> #t +bit-test: 0 1 -> #f byte 1318
[2009-08-06 10:42:54 UTC] sjamaan wrote:
Looks like the sign bit got unset somewhere down the line
[2009-08-06 11:39:04 UTC] sjamaan wrote:
The bitwise-and with a large unsigned integer on line 239 in maze.scm causes the result to be unsigned.
[2009-08-06 11:50:49 UTC] felix wrote:
Replying to sjamaan: > The bitwise-and with a large unsigned integer on line 239 in maze.scm causes the result to be unsigned. > > (bitwise-and -1 4611686018427387902) => 4611686018427387902
Isn't that correct?
BTW, block mode will have an influence because of increased constant folding.
[2009-08-06 11:55:11 UTC] sjamaan wrote:
yeah, it's correct. It took me a while to understand what the code was doing and what the issue at hand actually is. Never mind my silly comments :)
[2009-08-06 15:17:57 UTC] felix wrote:
The constant-folding of `(bitwise-not south)` results in a literal object that is incorrectly re-created. Doing `C_fix` on the result of `strtod` returns a wrong value.
[2009-08-11 14:09:08 UTC] felix changed status from new to closed
[2009-08-11 14:09:08 UTC] felix set resolution to fixed
[2009-08-11 14:09:08 UTC] felix wrote:
The problem appears to be that on 64-bit platforms, the fixnum-range exceeds the range of integers that can be stored in a double. While decoding a literal with `C_decode_literal`, the string->number conversion didn't take this into account. Fixed in r15413.