"maze" benchmark produces incorrect result when compiled wirth -block on x86-64

[felix winkelmann]

(reported by mario)

Some initial testing by adding debugging output to bit-test indicates a bit-twiddling problem.

[felix winkelmann]

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

[sjamaan]

Looks like the sign bit got unset somewhere down the line

[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

[felix winkelmann]

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.

[sjamaan]

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 :)

[felix winkelmann]

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.

[felix winkelmann]

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.

[(none)]

Milestone 4.2.0 deleted