enough information to reproduce the symptoms reliably, and if you say
clearly what the symptoms are. E.g. "There seems to be something wrong
with TAN of very small negative arguments. When I execute
-(TAN LEAST-NEGATIVE-SINGLE-FLOAT) interactively on sbcl-1.2.3 on my Linux
-4.5 X86 box, I get an UNBOUND-VARIABLE error."
+(TAN LEAST-NEGATIVE-SINGLE-FLOAT) interactively on sbcl-1.2.3 on my
+Linux 4.5 X86 box, I get an UNBOUND-VARIABLE error."
.SH SUPPORT
<http://sbcl.sourceforge.net/>. The mailing lists there are the
recommended place to look for support.
+.SH FILES
+
+.TP
+.I sbcl
+executable program containing some low-level runtime support and
+a loader, used to read sbcl.core
+.TP
+.I sbcl.core
+dumped memory image containing most of SBCL, to be loaded by the
+'sbcl' executable
+.TP
+.I sbclrc
+optional system-wide startup script (in an etc-ish system
+configuration file directory)
+.TP
+.I .sbclrc
+optional per-user customizable startup script (in user's home directory)
+
.SH AUTHORS
Dozens of people have made substantial contributions to SBCL and its
arg-locs nargs)))))
(values))
-;;; stuff to check in CHECK-FULL-CALL
+;;; stuff to check in PONDER-FULL-CALL
;;;
;;; There are some things which are intended always to be optimized
;;; away by DEFTRANSFORMs and such, and so never compiled into full
data-vector-set
data-vector-ref))
-;;; more stuff to check in CHECK-FULL-CALL
+;;; more stuff to check in PONDER-FULL-CALL
;;;
;;; These came in handy when troubleshooting cold boot after making
;;; major changes in the package structure: various transforms and
#!+sb-show (defvar *show-full-called-fnames-p* nil)
#!+sb-show (defvar *full-called-fnames* (make-hash-table :test 'equal))
-;;; Do some checks on a full call:
+;;; Do some checks (and store some notes relevant for future checks)
+;;; on a full call:
;;; * Is this a full call to something we have reason to know should
-;;; never be full called?
+;;; never be full called? (Except as of sbcl-0.7.18 or so, we no
+;;; longer try to ensure this behavior when *FAILURE-P* has already
+;;; been detected.)
;;; * Is this a full call to (SETF FOO) which might conflict with
;;; a DEFSETF or some such thing elsewhere in the program?
-(defun check-full-call (node)
+(defun ponder-full-call (node)
(let* ((cont (basic-combination-fun node))
(fname (continuation-fun-name cont t)))
(declare (type (or symbol cons) fname))
(basic-combination-args node))))
(/show arg-types)))
- (when (memq fname *always-optimized-away*)
- (/show (policy node speed) (policy node safety))
- (/show (policy node compilation-speed))
- (bug "full call to ~S" fname))
+ ;; When illegal code is compiled, all sorts of perverse paths
+ ;; through the compiler can be taken, and it's much harder -- and
+ ;; probably pointless -- to guarantee that always-optimized-away
+ ;; functions are actually optimized away. Thus, we skip the check
+ ;; in that case.
+ (unless *failure-p*
+ (when (memq fname *always-optimized-away*)
+ (/show (policy node speed) (policy node safety))
+ (/show (policy node compilation-speed))
+ (bug "full call to ~S" fname)))
(when (consp fname)
(destructuring-bind (setf stem) fname
;;; multiple-values call.
(defun ir2-convert-full-call (node block)
(declare (type combination node) (type ir2-block block))
- (check-full-call node)
+ (ponder-full-call node)
(let ((2cont (continuation-info (node-cont node))))
(cond ((node-tail-p node)
(ir2-convert-tail-full-call node block))
(defun stupid-input-to-smart-array-deftransforms-0-7-5-12 (v)
(declare (type (and simple-vector fwd-type-ref) v))
(aref v 0))
+
+;;; Ca. sbcl-0.7.5.15 the compiler would fail an internal consistency
+;;; check on this code because it expected all calls to %INSTANCE-REF
+;;; to be transformed away, but its expectations were dashed by perverse
+;;; code containing app programmer errors like this.
+(defstruct something-known-to-be-a-struct x y)
+(multiple-value-bind (fun warnings-p failure-p)
+ (compile nil
+ '(lambda ()
+ (labels ((a1 (a2 a3)
+ (cond (t (a4 a2 a3))))
+ (a4 (a2 a3 a5 a6)
+ (declare (type (or simple-vector null) a5 a6))
+ (something-known-to-be-a-struct-x a5))
+ (a8 (a2 a3)
+ (a9 #'a1 a10 a2 a3))
+ (a11 (a2 a3)
+ (cond ((and (funcall a12 a2)
+ (funcall a12 a3))
+ (funcall a13 a2 a3))
+ (t
+ (when a14
+ (let ((a15 (a1 a2 a3)))
+ ))
+ a16))))
+ (values #'a17 #'a11))))
+ ;; Python sees the structure accessor on the known-not-to-be-a-struct
+ ;; A5 value and is very, very disappointed in you. (But it doesn't
+ ;; signal BUG any more.)
+ (assert failure-p))
\f
;;;; tests not in the problem domain, but of the consistency of the
;;;; compiler machinery itself