failed in FIND-IN-PHYSENV instead. Fixes in sbcl-0.7.1.3 (not
closing over unreferenced variables) made this second test case
compile without error, but the original test case still fails.
+
+ Another way to get rid of the DEFTYPE without changing the symptom
+ of the bug is
+ (defvar *ch*)
+ (defun parse-num (string ind)
+ (flet ((digs ()
+ (let ()
+ (if (and (< ind ind)
+ (sb-int:memq *ch* '(#\1)))
+ nil))))))
+ In sbcl-0.7.1.3, this fails with
+ internal error, failed AVER: "(= (LENGTH (BLOCK-SUCC CALL-BLOCK)) 1)"
+ The problem occurs while the inline expansion of MEMQ,
+ #<LAMBDA :%DEBUG-NAME "varargs entry point for SB-C::.ANONYMOUS.">
+ is being LET-converted after having its second REF deleted, leaving
+ it with only one entry in LEAF-REFS.
148:
In sbcl-0.7.1.3 on x86, COMPILE-FILE on this file
alien code or from unsafe Lisp code; or there might be a bug ~
in the OS or hardware that SBCL is running on.) If it seems to ~
be a bug in SBCL itself, the maintainers would like to know ~
- how to exercise the bug so it can be fixed. Bug reports are ~
- welcome on the SBCL mailing lists, which you can find at ~
+ about it. Bug reports are welcome on the SBCL ~
+ mailing lists, which you can find at ~
<http://sbcl.sourceforge.net/>.~:@>"
'((fmakunbound 'compile))))))
(defun bug (format-control &rest format-arguments)
(sb-ext:gc-on)
(sb-ext:gc))
-;;; FIXME: I'm now inclined to make all the bootstrap stuff run in CL-USER
-;;; instead of SB-COLD. If I do so, I should first take care to
-;;; UNINTERN any old stuff in CL-USER, since ANSI says (11.1.2.2, "The
-;;; COMMON-LISP-USER Package") that CL-USER can have arbitrary symbols in
-;;; it. (And of course I should set the USE list to only CL.)
+;;; SB-COLD holds stuff used to build the initial SBCL core file
+;;; (including not only the final construction of the core file, but
+;;; also the preliminary steps like e.g. building the cross-compiler
+;;; and running the cross-compiler to produce target FASL files).
(defpackage "SB-COLD" (:use "CL"))
+
(in-package "SB-COLD")
;;; prefixes for filename stems when cross-compiling. These are quite arbitrary
;;; "host-objects/" or absolute pathnames (e.g. "/tmp/sbcl-xc-host-objects/").
;;;
;;; The cross-compilation process will force the creation of these directories
-;;; by executing CL:ENSURE-DIRECTORIES-EXIST (on the host Common Lisp).
+;;; by executing CL:ENSURE-DIRECTORIES-EXIST (on the xc host Common Lisp).
(defvar *host-obj-prefix*)
(defvar *target-obj-prefix*)
-;;; suffixes for filename stems when cross-compiling. Everything
-;;; should work fine for any arbitrary string values here. With more
-;;; work maybe we could cause these automatically to become the
-;;; traditional extensions for whatever host and target architectures
-;;; (e.g. ".x86f" or ".axpf") we're currently doing. That would make
-;;; it easier for a human looking at the temporary files to figure out
-;;; what they're for, but it's not necessary for the compilation
-;;; process to work, so we haven't bothered.
-(defvar *host-obj-suffix* ".lisp-obj")
-(defvar *target-obj-suffix* ".lisp-obj")
+;;; suffixes for filename stems when cross-compiling
+(defvar *host-obj-suffix*
+ (or
+ ;; On some xc hosts, it's impossible to LOAD a fasl file unless it
+ ;; has the same extension that the host uses for COMPILE-FILE
+ ;; output, so we have to be careful to use the xc host's preferred
+ ;; extension.
+ ;;
+ ;; FIXME: This is a little ugly and annoying to maintain. And
+ ;; there's very likely some way to rearrange the build process so
+ ;; that we never explicitly refer to host object file suffixes,
+ ;; only to the result of CL:COMPILE-FILE-PATHNAME.
+ #+lispworks ".ufsl" ; as per Lieven Marchand sbcl-devel 2002-02-01
+ ;; On most xc hosts, any old extension works, so we use an
+ ;; arbitrary one.
+ ".lisp-obj"))
+(defvar *target-obj-suffix*
+ ;; Target fasl files are LOADed (actually only quasi-LOADed, in
+ ;; GENESIS) only by SBCL code, and it doesn't care about particular
+ ;; extensions, so we can use something arbitrary.
+ ".lisp-obj")
;;; a function of one functional argument, which calls its functional argument
;;; in an environment suitable for compiling the target. (This environment
;;; variable has no references.
;;;
;;; [### For now, don't delete potentially flushable calls when they
-;;; have the CALL attribute. Someday we should look at the funcitonal
+;;; have the CALL attribute. Someday we should look at the functional
;;; args to determine if they have any side-effects.]
(defun flush-dead-code (block)
(declare (type cblock block))
(defun transform-call (node res)
(declare (type combination node) (list res))
(with-ir1-environment-from-node node
- (let ((new-fun (ir1-convert-inline-lambda
- res
- :debug-name "something inlined in TRANSFORM-CALL"))
+ (let ((new-fun (ir1-convert-inline-lambda
+ res
+ :debug-name "something inlined in TRANSFORM-CALL"))
(ref (continuation-use (combination-fun node))))
(change-ref-leaf ref new-fun)
(setf (combination-kind node) :full)
;;;
;;; the problem, part II: The <something> is represented as a pair
;;; of values, SOURCE-NAME and DEBUG-NAME, where SOURCE-NAME is used
-;;; if it's not null.
+;;; if it's not .ANONYMOUS. (This is parallel to the way that ordinarily
+;;; we don't use a value if it's NIL, instead defaulting it. But we
+;;; can't safely/comfortably use NIL for that in this context, since
+;;; the app programmer can use NIL as a name, so we use the private
+;;; symbol .ANONYMOUS. instead.)
;;;
;;; the solution: Use this function to convert whatever it is to a
;;; string, which FORMAT can then splice using "~A".
(defun as-debug-name (source-name debug-name)
- (if source-name
- (debug-namify "~S" source-name)
- debug-name))
+ (if (eql source-name '.anonymous.)
+ debug-name
+ (debug-namify "~S" source-name)))
;;; Return a COMPILER-ERROR-CONTEXT structure describing the current
;;; error context, or NIL if we can't figure anything out. ARGS is a
(unless (eq (defined-fun-inlinep var) :inline)
(setf (defined-fun-inline-expansion var) nil))
(let* ((name (leaf-source-name var))
- (fun (funcall converter lambda :source-name name))
+ (fun (funcall converter lambda
+ :source-name name))
(fun-info (info :function :info name)))
(setf (functional-inlinep fun) (defined-fun-inlinep var))
(assert-new-definition var fun)
;;; Dispatch to the appropriate function to attempt to convert a call.
;;; REF must be a reference to a FUNCTIONAL. This is called in IR1
-;;; optimize as well as in local call analysis. If the call is is
+;;; optimization as well as in local call analysis. If the call is is
;;; already :LOCAL, we do nothing. If the call is already scheduled
;;; for deletion, also do nothing (in addition to saving time, this
;;; also avoids some problems with optimizing collections of functions
;; skewed enough (e.g. for macro functions or method functions) that
;; we don't want to have that name affect compilation
;;
+ ;; (We use .ANONYMOUS. here more or less the way we'd ordinarily use
+ ;; NIL, but we're afraid to use NIL because it's a symbol which could
+ ;; be the name of a leaf, if only the constant named NIL.)
+ ;;
;; The value of this slot in can affect ordinary runtime behavior,
;; e.g. of special variables and known functions, not just debugging.
;;
;;; for internal versions, especially for internal versions off the
;;; main CVS branch, it gets hairier, e.g. "0.pre7.14.flaky4.13".)
-"0.7.1.3"
+"0.7.1.4"
projects / sbcl.git / commitdiff