Bug #1177703 reported by Jan Moringen on 2013-05-08
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

What I do (reduced test case courtesy of stassats):
(declaim (inline vec))
(defstruct (vec (:constructor vec (&optional x)))
  (x 0.0d0 :type double-float))

(declaim (inline norm))
(defun norm (v)
  (vec (sqrt (vec-x v))))

(defun radiance (x)
  (norm (vec x)))

What happens:
an error is signaled form within the compiler:
debugger invoked on a SIMPLE-ERROR in thread
#<THREAD "main thread" RUNNING {AB46B49}>:
  #<SB-C:TN t1> is not valid as the second argument to VOP:
Primitive type: T
SC restrictions:
The primitive type disallows these loadable SCs:

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [RETRY ] Retry EVAL of current toplevel form.
  1: [CONTINUE] Ignore error and continue loading file "/tmp/reproduce2.lisp".
  2: [ABORT ] Abort loading file "/tmp/reproduce2.lisp".
  3: Ignore runtime option --load "/tmp/reproduce2.lisp".
  4: Skip rest of --eval and --load options.
  5: Skip to toplevel READ/EVAL/PRINT loop.
  6: [EXIT ] Exit SBCL (calling #'EXIT, killing the process).


What did I expect to happen:
The compiler would either compile the code without signaling an error or signal an error explaining the problem with the above code.

SBCL version: ~ 1.1.7

$ uname -a
Linux ferberit 3.5.0-28-lowlatency #32-Ubuntu SMP PREEMPT Fri Apr 26 11:05:36 UTC 2013 i686 i686 i686 GNU/Linux


Stas Boukarev (stassats) on 2013-05-08
Changed in sbcl:
importance: Undecided → Medium
status: New → Triaged
Paul Khuong (pvk) wrote :

The patch below inserts an explicit check when necessary. I haven't really dug deep, but it seems that we only emit type checks when the declared slot type differs from its raw slot type?

Adding more checking code seems like a sane avenue, except that it'd increase our reliance on clever type propagation...

Paul Khuong (pvk) wrote :

Another option is to partially revert and reinstate declarations inside the definition (in addition to the ftype). This is basically another instance of the float-radix bug. Is there a nice way to apply declaimed ftypes when expanding inline definitions?

Paul Khuong (pvk) on 2013-05-18
Changed in sbcl:
status: Triaged → Fix Committed
Changed in sbcl:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers