Some TN not valid for RAW-INSTANCE-INIT/DOUBLE

[Jan Moringen]

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:
  SB-VM::RAW-INSTANCE-INIT/DOUBLE
Primitive type: T
SC restrictions:
  (SB-VM::DOUBLE-REG)
The primitive type disallows these loadable SCs:
  (SB-VM::DOUBLE-REG)

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

(SB-C::BAD-COERCE-ERROR #<SB-C:TN-REF :TN #<SB-C:TN t1> :WRITE-P NIL :VOP SB-VM::RAW-INSTANCE-INIT/DOUBLE>)

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

*FEATURES*:
(:ALIEN-CALLBACKS :ANSI-CL :C-STACK-IS-CONTROL-STACK :COMMON-LISP
 :COMPARE-AND-SWAP-VOPS :CYCLE-COUNTER :ELF :GENCGC :IEEE-FLOATING-POINT
 :INLINE-CONSTANTS :LARGEFILE :LINKAGE-TABLE :LINUX :LITTLE-ENDIAN
 :MEMORY-BARRIER-VOPS :MULTIPLY-HIGH-VOPS :OS-PROVIDES-BLKSIZE-T
 :OS-PROVIDES-DLADDR :OS-PROVIDES-DLOPEN :OS-PROVIDES-GETPROTOBY-R
 :OS-PROVIDES-POLL :OS-PROVIDES-PUTWC :OS-PROVIDES-SUSECONDS-T
 :PACKAGE-LOCAL-NICKNAMES :RAW-INSTANCE-INIT-VOPS :SB-DOC :SB-EVAL :SB-FUTEX
 :SB-LDB :SB-PACKAGE-LOCKS :SB-SOURCE-LOCATIONS :SB-TEST :SB-THREAD :SB-UNICODE
 :SBCL :STACK-ALLOCATABLE-CLOSURES :STACK-ALLOCATABLE-FIXED-OBJECTS
 :STACK-ALLOCATABLE-LISTS :STACK-ALLOCATABLE-VECTORS
 :STACK-GROWS-DOWNWARD-NOT-UPWARD :UNIX :UNWIND-TO-FRAME-AND-CALL-VOP :X86)

[Paul Khuong (pvk)]

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

Another option is to partially revert 1.0.47.3 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?