Incorrect improper argument number error in compiled code (random tester)

[Paul F. Dietz]

(defun f16 (b)
  (declare (type (integer -19783977 -14446514) b))
  (ceiling 0 (min -90 (- b (mod (complex b 0) (min -30 0))))))

(f16 -18884888)

==>

invalid number of arguments: -18884888

[Paul F. Dietz (paul-f-dietz)]

Reduced the integers:

(defun f16b (b)
  (declare (type (integer -62 -61) b))
  (ceiling 0 (min -90 (- b (mod (complex b 0) (min -30 0))))))

(f16b -61) ==> invalid number of arguments: -61

Increasing the upper bound to -60 makes the bug disappear.

[Paul F. Dietz (paul-f-dietz)]

This bug showed up in an extended random tester run over the weekend using an image built last friday, but it still shows up in the current build.

[Paul F. Dietz (paul-f-dietz)]

There are some other randomized tests in ansi-tests/random that would catch this. In particular, RANDOM-TYPE-PROP.TRUNCATE.3 catches it after a few thousand iterations. I should run these all again and report failures; they're fast.

[Stas Boukarev (stassats)]

78e5ccc6df3df241c89e2218a8b0a103705366c2

[Paul F. Dietz (paul-f-dietz)]

Now getting a control stack exhaustion:

(funcall (compile nil '(lambda () (truncate -8595152206133 99839.96))))

fatal error encountered in SBCL pid 15652(tid 0x7ffff7fda700):
Control stack exhausted, fault: 0x7ffff1cbfff8, PC: 0x21bc44f9

[Paul F. Dietz (paul-f-dietz)]

This does not look right:

* (disassemble (compile nil '(lambda () (truncate -8595152206133 99839.96))))

; disassembly for (LAMBDA ())
; Size: 11 bytes. Origin: #x1002C6F31C
; 1C: 498B4C2460 MOV RCX, [R12+96] ; no-arg-parsing entry point
                                                              ; thread.binding-stack-pointer
; 21: 48894DF8 MOV [RBP-8], RCX
; 25: CC10 BREAK 16 ; Invalid argument count trap
NIL

[Paul F. Dietz (paul-f-dietz)]

Still seeing a failure:

* (compile nil '(lambda () (floor -114658225103614 84619.58)))

#<FUNCTION (LAMBDA ()) {10048D002B}>
NIL
NIL
* (funcall *)
fatal error encountered in SBCL pid 15182(tid 0x7ffff7fda700):
Control stack exhausted, fault: 0x7ffff1cbfff8, PC: 0x21bc44f9

[Stas Boukarev (stassats)]

That's a different problem caused by precision loss in type derivation. Fixed in 629e30b8d896ab8ad77acbabb25fd1e932efeb99. There may be more, just open new tickets for them.

It used to silently derive wrong types until I changed the order in which constant folding and type derivation happens, so it now happens to conflict.
If you want to test type derivation problems in general you can do

(lambda ()
  (declare (notinline floor)) ;; only needed to disable constant folding
  (= (floor -114658225103614 84619.58) -1354984705))

it returns NIL on older versions.