Hi developers,

Below is a minimized version of some code which elicits a compiler bug preventing access to half of this constant array. 
-31 to -1 are good arguments to FOO - they should index the zeroth element of the array onward.

* (defun compute-my-array () (make-array 63))

* (defun foo (v)                                                                                                                        
  (if (typep v '(integer -31 31))                                                                                                       
      (let ((index (+ v 31)))                                                                                                           
        (aref #.(compute-my-array) index))                                                                                              
      (error "Bad val: ~S" v)))

* (foo -31)
debugger invoked on a TYPE-ERROR in thread
#<THREAD "main thread" RUNNING {10029F94B3}>:
  The value -31 is not of type (MOD 4611686018427387901).

The disassembly is illuminating:

; disassembly for FOO
; 02AB99EC:       F6C301           TEST BL, 1                 ; no-arg-parsing entry point
;      9EF:       7543             JNE L1
;      9F1:       488BCB           MOV RCX, RBX
;      9F4:       4883F9C2         CMP RCX, -62
;      9F8:       7C3A             JL L1
;      9FA:       488BCB           MOV RCX, RBX
;      9FD:       4883F93E         CMP RCX, 62
;      A01:       7F31             JNLE L1
;      A03:       488BCB           MOV RCX, RBX
;      A06:       4883F900         CMP RCX, 0
;      A0A:       7C18             JL L0
;      A0C:       488BCB           MOV RCX, RBX
;      A0F:       488B056AFFFFFF   MOV RAX, [RIP-150]         ; #(0 0 0 0 ...)
;      A16:       488B9488F9000000 MOV RDX, [RAX+RCX*4+249]

The optimization of using the SIB addressing mode to fold in the constant offset of 31 has not informed the bound check that the valid range of the index (register RCX) is -31 to 31 - and the explicit typep check has already concluded that that it is exactly in that range.  The "CMP RCX, 0 / JL L0" is bogus.  (L0 is the label for the error trap)

I haven't yet checked how this affects SVREF in the latest code which bypasses some parts of the AREF transforms.