X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;ds=sidebyside;f=BUGS;h=7f62d6ce23ae7df5a428f8a25e3462e8222e3738;hb=ed891a4fd882d1b9fe066ab14bcf2107aea95baa;hp=be6f90626dfb9e26bdb0311180f0e6bec498aeba;hpb=60639facf7d4e266d729a9c89f333618c9b2e8e2;p=sbcl.git diff --git a/BUGS b/BUGS index be6f906..7f62d6c 100644 --- a/BUGS +++ b/BUGS @@ -84,12 +84,6 @@ WORKAROUND: d: (fixed in 0.8.1.5) -27: - Sometimes (SB-EXT:QUIT) fails with - Argh! maximum interrupt nesting depth (4096) exceeded, exiting - Process inferior-lisp exited abnormally with code 1 - I haven't noticed a repeatable case of this yet. - 33: And as long as we're wishing, it would be awfully nice if INSPECT could also report on closures, telling about the values of the bound variables. @@ -174,6 +168,9 @@ WORKAROUND: e-mail on cmucl-help@cons.org on 2001-01-16 and 2001-01-17 from WHN and Pierre Mai.) + (Actually this has changed changed since, and types as above are + now supported. This may be a bug.) + 83: RANDOM-INTEGER-EXTRA-BITS=10 may not be large enough for the RANDOM RNG to be high quality near RANDOM-FIXNUM-MAX; it looks as though @@ -252,20 +249,17 @@ WORKAROUND: comfortable merging the patches in the CVS version of SBCL. 108: - (TIME (ROOM T)) reports more than 200 Mbytes consed even for - a clean, just-started SBCL system. And it seems to be right: - (ROOM T) can bring a small computer to its knees for a *long* - time trying to GC afterwards. Surely there's some more economical - way to implement (ROOM T). + ROOM issues: - Daniel Barlow doesn't know what fixed this, but observes that it - doesn't seem to be the case in 0.8.7.3 any more. Instead, (ROOM T) - in a fresh SBCL causes + a) ROOM works by walking over the heap linearly, instead of + following the object graph. Hence, it report garbage objects that + are unreachable. (Maybe this is a feature and not a bug?) - debugger invoked on a SB-INT:BUG in thread 5911: - failed AVER: "(SAP= CURRENT END)" - - unless a GC has happened beforehand. + b) ROOM uses MAP-ALLOCATED-OBJECTS to walk the heap, which doesn't + check all pointers as well as it should, and can hence become + confused, leading to aver failures. As of 1.0.13.21 these (the + SAP= aver in particular) should be mostly under control, but push + ROOM hard enough and it still might croak. 117: When the compiler inline expands functions, it may be that different @@ -485,6 +479,11 @@ WORKAROUND: (print (incf start 22)) (print (incf start 26)))))) + [ Update: 1.0.14.36 improved this quite a bit (20-25%) by + eliminating useless work from PROPAGATE-FROM-SETS -- but as alluded + below, maybe we should be smarter about when to decide a derived + type is "good enough". ] + This example could be solved with clever enough constraint propagation or with SSA, but consider @@ -557,11 +556,6 @@ WORKAROUND: c. The cross-compiler cannot inline functions defined in a non-null lexical environment. -206: ":SB-FLUID feature broken" - (reported by Antonio Martinez-Shotton sbcl-devel 2002-10-07) - Enabling :SB-FLUID in the target-features list in sbcl-0.7.8 breaks - the build. - 207: "poorly distributed SXHASH results for compound data" SBCL's SXHASH could probably try a little harder. ANSI: "the intent is that an implementation should make a good-faith @@ -635,31 +629,6 @@ WORKAROUND: This is probably the same bug as 162 -217: "Bad type operations with FUNCTION types" - In sbcl.0.7.7: - - * (values-type-union (specifier-type '(function (base-char))) - (specifier-type '(function (integer)))) - - # - - It causes insertion of wrong type assertions into generated - code. E.g. - - (defun foo (x s) - (let ((f (etypecase x - (character #'write-char) - (integer #'write-byte)))) - (funcall f x s) - (etypecase x - (character (write-char x s)) - (integer (write-byte x s))))) - - Then (FOO #\1 *STANDARD-OUTPUT*) signals type error. - - (In 0.7.9.1 the result type is (FUNCTION * *), so Python does not - produce invalid code, but type checking is not accurate.) - 235: "type system and inline expansion" a. (declaim (ftype (function (cons) number) acc)) @@ -675,6 +644,10 @@ WORKAROUND: (foo '(nil) '(t)) => NIL, T. + As of 0.9.15.41 this seems to be due to ACC being inlined only once + inside FOO, which results in the second call reusing the FUNCTIONAL + resulting from the first -- which doesn't check the type. + 237: "Environment arguments to type functions" a. Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and UPGRADED-COMPLEX-PART-TYPE now have an optional environment @@ -753,11 +726,7 @@ WORKAROUND: a. (lambda () (svref (make-array 8 :adjustable t) 1)) - b. (lambda (x) - (list (let ((y (the real x))) - (unless (floatp y) (error "")) - y) - (integer-length x))) + b. (fixed at some point before 1.0.4.10) c. (lambda (x) (declare (optimize (debug 0))) @@ -904,11 +873,9 @@ WORKAROUND: 283: Thread safety: libc functions There are places that we call unsafe-for-threading libc functions that we should find alternatives for, or put locks around. Known or - strongly suspected problems, as of 0.8.3.10: please update this + strongly suspected problems, as of 1.0.3.13: please update this bug instead of creating new ones - gethostbyname, gethostbyaddr in sb-bsd-sockets - 284: Thread safety: special variables There are lots of special variables in SBCL, and I feel sure that at least some of them are indicative of potentially thread-unsafe @@ -1009,13 +976,8 @@ WORKAROUND: The problem is that both EVALs sequentially write to the same LVAR. 306: "Imprecise unions of array types" - a.(defun foo (x) - (declare (optimize speed) - (type (or (array cons) (array vector)) x)) - (elt (aref x 0) 0)) - (foo #((0))) => TYPE-ERROR - relatedly, + a. fixed in SBCL 0.9.15.48 b.(subtypep 'array @@ -1407,54 +1369,6 @@ WORKAROUND: Expected: # Got: # -361: initialize-instance of standard-reader-method ignores :function argument - (reported by Bruno Haible) - Pass a custom :function argument to initialize-instance of a - standard-reader-method instance, but it has no effect. - ;; Check that it's possible to define reader methods that do typechecking. - (progn - (defclass typechecking-reader-method (sb-pcl:standard-reader-method) - ()) - (defmethod initialize-instance ((method typechecking-reader-method) &rest initargs - &key slot-definition) - (let ((name (sb-pcl:slot-definition-name slot-definition)) - (type (sb-pcl:slot-definition-type slot-definition))) - (apply #'call-next-method method - :function #'(lambda (args next-methods) - (declare (ignore next-methods)) - (apply #'(lambda (instance) - (let ((value (slot-value instance name))) - (unless (typep value type) - (error "Slot ~S of ~S is not of type ~S: ~S" - name instance type value)) - value)) - args)) - initargs))) - (defclass typechecking-reader-class (standard-class) - ()) - (defmethod sb-pcl:validate-superclass ((c1 typechecking-reader-class) (c2 standard-class)) - t) - (defmethod reader-method-class ((class typechecking-reader-class) direct-slot &rest args) - (find-class 'typechecking-reader-method)) - (defclass testclass25 () - ((pair :type (cons symbol (cons symbol null)) :initarg :pair :accessor testclass25-pair)) - (:metaclass typechecking-reader-class)) - (macrolet ((succeeds (form) - `(not (nth-value 1 (ignore-errors ,form))))) - (let ((p (list 'abc 'def)) - (x (make-instance 'testclass25))) - (list (succeeds (make-instance 'testclass25 :pair '(seventeen 17))) - (succeeds (setf (testclass25-pair x) p)) - (succeeds (setf (second p) 456)) - (succeeds (testclass25-pair x)) - (succeeds (slot-value x 'pair)))))) - Expected: (t t t nil t) - Got: (t t t t t) - - (inspect (first (sb-pcl:generic-function-methods #'testclass25-pair))) - shows that the method was created with a FAST-FUNCTION slot but with a - FUNCTION slot of NIL. - 362: missing error when a slot-definition is created without a name (reported by Bruno Haible) The MOP says about slot-definition initialization: @@ -1478,80 +1392,6 @@ WORKAROUND: Expected: ERROR Got: # -367: TYPE-ERROR at compile time, undetected TYPE-ERROR at runtime - This test program - (declaim (optimize (safety 3) (debug 2) (speed 2) (space 1))) - (defstruct e367) - (defstruct i367) - (defstruct g367 - (i367s (make-array 0 :fill-pointer t) :type (or (vector i367) null))) - (defstruct s367 - (g367 (error "missing :G367") :type g367 :read-only t)) - ;;; In sbcl-0.8.18, commenting out this (DECLAIM (FTYPE ... R367)) - ;;; gives an internal error at compile time: - ;;; The value # is not of - ;;; type SB-KERNEL:VALUES-TYPE. - (declaim (ftype (function ((vector i367) e367) (or s367 null)) r367)) - (declaim (ftype (function ((vector e367)) (values)) h367)) - (defun frob (v w) - (let ((x (g367-i367s (make-g367)))) - (let* ((y (or (r367 x w) - (h367 x))) - (z (s367-g367 y))) - (format t "~&Y=~S Z=~S~%" y z) - (g367-i367s z)))) - (defun r367 (x y) (declare (ignore x y)) nil) - (defun h367 (x) (declare (ignore x)) (values)) - ;;; In sbcl-0.8.18, executing this form causes an low-level error - ;;; segmentation violation at #X9B0E1F4 - ;;; (instead of the TYPE-ERROR that one might like). - (frob 0 (make-e367)) - can be made to cause two different problems, as noted in the comments: - bug 367a: Compile and load the file. No TYPE-ERROR is signalled at - run time (in the (S367-G367 Y) form of FROB, when Y is NIL - instead of an instance of S367). Instead (on x86/Linux at least) - we end up with a segfault. - bug 367b: Comment out the (DECLAIM (FTYPE ... R367)), and compile - the file. The compiler fails with TYPE-ERROR at compile time. - -368: miscompiled OR (perhaps related to bug 367) - Trying to relax type declarations to find a workaround for bug 367, - it turns out that even when the return type isn't declared (or - declared to be T, anyway) the system remains confused about type - inference in code similar to that for bug 367: - (in-package :cl-user) - (declaim (optimize (safety 3) (debug 2) (speed 2) (space 1))) - (defstruct e368) - (defstruct i368) - (defstruct g368 - (i368s (make-array 0 :fill-pointer t) :type (or (vector i368) null))) - (defstruct s368 - (g368 (error "missing :G368") :type g368 :read-only t)) - (declaim (ftype (function (fixnum (vector i368) e368) t) r368)) - (declaim (ftype (function (fixnum (vector e368)) t) h368)) - (defparameter *h368-was-called-p* nil) - (defun nsu (vertices e368) - (let ((i368s (g368-i368s (make-g368)))) - (let ((fuis (r368 0 i368s e368))) - (format t "~&FUIS=~S~%" fuis) - (or fuis (h368 0 i368s))))) - (defun r368 (w x y) - (declare (ignore w x y)) - nil) - (defun h368 (w x) - (declare (ignore w x)) - (setf *h368-was-called-p* t) - (make-s368 :g368 (make-g368))) - (trace r368 h368) - (format t "~&calling NSU~%") - (let ((nsu (nsu #() (make-e368)))) - (format t "~&NSU returned ~S~%" nsu) - (format t "~&*H368-WAS-CALLED-P*=~S~%" *h368-was-called-p*) - (assert (s368-p nsu)) - (assert *h368-was-called-p*)) - In sbcl-0.8.18, both ASSERTs fail, and (DISASSEMBLE 'NSU) shows - that no call to H368 is compiled. - 369: unlike-an-intersection behavior of VALUES-TYPE-INTERSECTION In sbcl-0.8.18.2, the identity $(x \cap y \cap y)=(x \cap y)$ does not hold for VALUES-TYPE-INTERSECTION, even for types which @@ -1626,18 +1466,6 @@ WORKAROUND: tries to find and remove a method with an incompatible lambda list from the unrelated generic function. -381: incautious calls to EQUAL in fasl dumping - Compiling - (frob #(#1=(a #1#))) - (frob #(#1=(b #1#))) - (frob #(#1=(a #1#))) - in sbcl-0.9.0 causes CONTROL-STACK-EXHAUSTED. My (WHN) impression - is that this follows from the use of (MAKE-HASH-TABLE :TEST 'EQUAL) - to detect sharing, in which case fixing it might require either - getting less ambitious about detecting shared list structure, or - implementing the moral equivalent of EQUAL hash tables in a - cycle-tolerant way. - 382: externalization unexpectedly changes array simplicity COMPILE-FILE and LOAD (defun foo () @@ -1689,16 +1517,6 @@ WORKAROUND: stack exhaustion checking (implemented with a write-protected guard page) does not work on SunOS/x86. -387: - 12:10 < jsnell> the package-lock test is basically due to a change in the test - behaviour when you install a handler for error around it. I - thought I'd disabled the test for now, but apparently that was - my imagination - 12:19 < Xophe> jsnell: ah, I see the problem in the package-locks stuff - 12:19 < Xophe> it's the same problem as we had with compiler-error conditions - 12:19 < Xophe> the thing that's signalled up and down the stack is a subtype of - ERROR, where it probably shouldn't be - 388: (found by Dmitry Bogomolov) @@ -1794,22 +1612,6 @@ WORKAROUND: For some more details see comments for (define-alien-type-method (c-string :deport-gen) ...) in host-c-call.lisp. -402: "DECLAIM DECLARATION does not inform the PCL code-walker" - reported by Vincent Arkesteijn: - - (declaim (declaration foo)) - (defgeneric bar (x)) - (defmethod bar (x) - (declare (foo x)) - x) - - ==> WARNING: The declaration FOO is not understood by - SB-PCL::SPLIT-DECLARATIONS. - Please put FOO on one of the lists SB-PCL::*NON-VAR-DECLARATIONS*, - SB-PCL::*VAR-DECLARATIONS-WITH-ARG*, or - SB-PCL::*VAR-DECLARATIONS-WITHOUT-ARG*. - (Assuming it is a variable declaration without argument). - 403: FORMAT/PPRINT-LOGICAL-BLOCK of CONDITIONs ignoring *PRINT-CIRCLE* In sbcl-0.9.13.34, (defparameter *c* @@ -1860,3 +1662,304 @@ WORKAROUND: VECTOR-POP: #() has length zero perhaps because CLISP has shuffled the clauses into an ANSI-compliant order before proceeding. + +405: a TYPE-ERROR in MERGE-LETS exercised at DEBUG 3 + In sbcl-0.9.16.21 on linux/86, compiling + (declaim (optimize (debug 3))) + (defstruct foo bar) + (let () + (flet ((i (x) (frob x (foo-bar foo)))) + (i :five))) + causes a TYPE-ERROR + The value NIL is not of type SB-C::PHYSENV. + in MERGE-LETS. + +406: functional has external references -- failed aver + Given the following food in a single file + (eval-when (:compile-toplevel :load-toplevel :execute) + (defstruct foo3)) + (defstruct bar + (foo #.(make-foo3))) + as of 0.9.18.11 the file compiler breaks on it: + failed AVER: "(NOT (FUNCTIONAL-HAS-EXTERNAL-REFERENCES-P CLAMBDA))" + Defining the missing MAKE-LOAD-FORM method makes the error go away. + +407: misoptimization of loop, COERCE 'FLOAT, and HANDLER-CASE for bignums + (reported by Ariel Badichi on sbcl-devel 2007-01-09) + 407a: In sbcl-1.0.1 on Linux x86, + (defun foo () + (loop for n from (expt 2 1024) do + (handler-case + (coerce n 'single-float) + (simple-type-error () + (format t "Got here.~%") + (return-from foo))))) + (foo) + causes an infinite loop, where handling the error would be expected. + 407b: In sbcl-1.0.1 on Linux x86, + (defun bar () + (loop for n from (expt 2 1024) do + (handler-case + (format t "~E~%" (coerce n 'single-float)) + (simple-type-error () + (format t "Got here.~%") + (return-from bar))))) + fails to compile, with + Too large to be represented as a SINGLE-FLOAT: ... + from + 0: ((LABELS SB-BIGNUM::CHECK-EXPONENT) ...) + 1: ((LABELS SB-BIGNUM::FLOAT-FROM-BITS) ...) + 2: (SB-KERNEL:%SINGLE-FLOAT ...) + 3: (SB-C::BOUND-FUNC ...) + 4: (SB-C::%SINGLE-FLOAT-DERIVE-TYPE-AUX ...) + + These are now fixed, but (COERCE HUGE 'SINGLE-FLOAT) still signals a + type-error at runtime. The question is, should it instead signal a + floating-point overflow, or return an infinity? + +408: SUBTYPEP confusion re. OR of SATISFIES of not-yet-defined predicate + As reported by Levente M\'{e}sz\'{a}ros sbcl-devel 2006-02-20, + (aver (equal (multiple-value-list + (subtypep '(or (satisfies x) string) + '(or (satisfies x) integer))) + '(nil nil))) + fails. Also, beneath that failure lurks another failure, + (aver (equal (multiple-value-list + (subtypep 'string + '(or (satisfies x) integer))) + '(nil nil))) + Having looked at this for an hour or so in sbcl-1.0.2, and + specifically having looked at the output from + laptop$ sbcl + * (let ((x 'string) + (y '(or (satisfies x) integer))) + (trace sb-kernel::union-complex-subtypep-arg2 + sb-kernel::invoke-complex-subtypep-arg1-method + sb-kernel::type-union + sb-kernel::type-intersection + sb-kernel::type=) + (subtypep x y)) + my (WHN) impression is that the problem is that the semantics of TYPE= + are wrong for what the UNION-COMPLEX-SUBTYPEP-ARG2 code is trying + to use it for. The comments on the definition of TYPE= probably + date back to CMU CL and seem to define it as a confusing thing: + its primary value is something like "certainly equal," and its + secondary value is something like "certain about that certainty." + I'm left uncertain how to fix UNION-COMPLEX-SUBTYPEP-ARG2 without + reducing its generality by removing the TYPE= cleverness. Possibly + the tempting TYPE/= relative defined next to it might be a + suitable replacement for the purpose. Probably, though, it would + be best to start by reverse engineering exactly what TYPE= and + TYPE/= do, and writing an explanation which is so clear that one + can see immediately what it's supposed to mean in odd cases like + (TYPE= '(SATISFIES X) 'INTEGER) when X isn't defined yet. + +409: MORE TYPE SYSTEM PROBLEMS + Found while investigating an optimization failure for extended + sequences. The extended sequence type implementation was altered to + work around the problem, but the fundamental problem remains, to wit: + (sb-kernel:type= (sb-kernel:specifier-type '(or float ratio)) + (sb-kernel:specifier-type 'single-float)) + returns NIL, NIL on sbcl-1.0.3. + (probably related to bug #408) + +410: read circularities and type declarations + Consider the definition + (defstruct foo (a 0 :type (not symbol))) + followed by + (setf *print-circle* t) ; just in case + (read-from-string "#1=#s(foo :a #1#)") + This gives a type error (#:G1 is not a (NOT SYMBOL)) because of the + implementation of read circularity, using a symbol as a marker for + the previously-referenced object. + +415: Issues creating large arrays on x86-64/Linux and x86/Darwin + + (make-array (1- array-dimension-limit)) + + causes a GC invariant violation on x86-64/Linux, and + an unhandled SIGILL on x86/Darwin. + +416: backtrace confusion + + (defun foo (x) + (let ((v "foo")) + (flet ((bar (z) + (oops v z) + (oops z v))) + (bar x) + (bar v)))) + (foo 13) + + gives the correct error, but the backtrace shows + 1: (SB-KERNEL:FDEFINITION-OBJECT 13 NIL) + as the second frame. + +418: SUBSEQ on lists doesn't support bignum indexes + + LIST-SUBSEQ* now has all the works necessary to support bignum indexes, + but it needs to be verified that changing the DEFKNOWN doesn't kill + performance elsewhere. + + Other generic sequence functions have this problem as well. + +419: stack-allocated indirect closure variables are not popped + + (locally (declare (optimize sb-c::stack-allocate-dynamic-extent + sb-c::stack-allocate-value-cells)) + (defun bug419 (x) + (multiple-value-call #'list + (eval '(values 1 2 3)) + (let ((x x)) + (declare (dynamic-extent x)) + (flet ((mget (y) + (+ x y)) + (mset (z) + (incf x z))) + (declare (dynamic-extent #'mget #'mset)) + ((lambda (f g) (eval `(progn ,f ,g (values 4 5 6)))) #'mget #'mset)))))) + + (ASSERT (EQUAL (BUG419 42) '(1 2 3 4 5 6))) => failure + + Note: as of SBCL 1.0.26.29 this bug no longer affects user code, as + SB-C::STACK-ALLOCATE-VALUE-CELLS needs to be explicitly turned on for + that to happen. Proper fix for this bug requires (Nikodemus thinks) + storing the relevant LAMBDA-VARs in a :DYNAMIC-EXTENT cleanup, and + teaching stack analysis how to deal with them. + +420: The MISC.556 test from gcl/ansi-tests/misc.lsp fails hard. + +In sbcl-1.0.13 on Linux/x86, executing + (FUNCALL + (COMPILE NIL + '(LAMBDA (P1 P2) + (DECLARE + (OPTIMIZE (SPEED 1) (SAFETY 0) (DEBUG 0) (SPACE 0)) + (TYPE (MEMBER 8174.8604) P1) (TYPE (MEMBER -95195347) P2)) + (FLOOR P1 P2))) + 8174.8604 -95195347) +interactively causes + SB-SYS:MEMORY-FAULT-ERROR: Unhandled memory fault at #x8. +The gcl/ansi-tests/doit.lisp program terminates prematurely shortly after +MISC.556 by falling into gdb with + fatal error encountered in SBCL pid 2827: Unhandled SIGILL +unless the MISC.556 test is commented out. + +Analysis: + and a number of other arithmetic functions exhibit the +same behaviour. Here's the underlying problem: On x86 we perform +single-float + integer normally using double-precision, and then +coerce the result back to single-float. (The FILD instruction always +gives us a double-float, and unless we do MOVE-FROM-SINGLE it remains +one. Or so it seems to me, and that would also explain the observed +behaviour below.) + +During IR1 we derive the types for both + + (+ ) ; uses double-precision + (+ (FLOAT )) ; uses single-precision + +and get a mismatch for a number of unlucky arguments. This leads to +derived result type NIL, and ends up flushing the whole whole +operation -- and finally we generate code without a return sequence, +and fall through to whatever. + +The use of double-precision in the first case appears to be an +(un)happy accident -- interval arithmetic gives us the +double-precision result because that's what the backend does. + + (+ 8172.0 (coerce -95195347 'single-float)) ; => -9.518717e7 + (+ 8172.0 -95195347) ; => -9.5187176e7 + (coerce (+ 8172.0 (coerce -95195347 'double-float)) 'single-float) + ; => -9.5187176e7 + +Which should be fixed, the IR1, or the backend? + +421: READ-CHAR-NO-HANG misbehaviour on Windows Console: + + It seems that on Windows READ-CHAR-NO-HANG hangs if the user + has pressed a key, but not yet enter (ie. SYSREAD-MAY-BLOCK-P + seems to lie if the OS is buffering input for us on Console.) + + reported by Elliot Slaughter on sbcl-devel 2008/1/10. + +422: out-of-extent return not checked in safe code + + (declaim (optimize safety)) + (funcall (catch 't (block nil (throw 't (lambda () (return)))))) + +behaves ...erratically. Reported by Kevin Reid on sbcl-devel +2007-07-06. (We don't _have_ to check things like this, but we +generally try to check returns in safe code, so we should here too.) + +424: toplevel closures and *CHECK-CONSISTENCY* + + The following breaks under COMPILE-FILE if *CHECK-CONSISTENCY* is true. + + (let ((exported-symbols-alist + (loop for symbol being the external-symbols of :cl + collect (cons symbol + (concatenate 'string + "#" + (string-downcase symbol)))))) + (defun hyperdoc-lookup (symbol) + (cdr (assoc symbol exported-symbols-alist)))) + + (Test-case adapted from CL-PPCRE.) + +425: reading from closed streams + + Reported by Damien Cassou on sbcl-devel. REPL transcript follows: + + * (open ".bashrc" :direction :input) + # + * (defparameter *s* *) + *S* + * (read-line *s*) + "# -*- Mode: Sh -*-" + * (read-line *s*) + "# Files you make look like rw-r--r--" + * (open-stream-p *s*) + T + * (close *s*) + T + * (open-stream-p *s*) + NIL + * (read-line *s*) + "umask 022" + + The problem is with the fast path using ansi-stream-cin-buffer not hitting + closed-flame. + +426: inlining failure involving multiple nested calls + + (declaim (inline foo)) + (defun foo (x y) + (cons x y)) + (defun bar (x) + (foo (foo x x) (foo x x))) + ;; shows a full call to FOO + (disassemble 'bar) + ;; simple way to test this programmatically + (let ((code (sb-c::fun-code-header #'bar)) + (foo (sb-impl::fdefinition-object 'foo nil))) + (loop for i from sb-vm:code-constants-offset below (sb-kernel:get-header-data code) + do (assert (not (eq foo (sb-kernel:code-header-ref code i)))))) + + This appears to be an ancient bug, inherited from CMUCL: reportedly + 18c does the same thing. RECOGNIZE-KNOWN-CALL correctly picks up only + one of the calls, but local call analysis fails to inline the call + for the second time. Nikodemus thinks (but is not 100% sure based on + very brief investigation) that the call that is not inlined is the + second nested one. A trivial fix is to call CHANGE-REF-LEAF in known + call for functions already inline converted there, but he is not sure + if this has adverse effects elsewhere. + +427: ANY-REG not good for primitive type T + + ...which is true, of course, but the following should not complain + about it (on x86 and x86-64): + + (sb-alien:with-alien ((buf (array (sb-alien:signed 8) 16)))) + + reported by Stelian Ionescu on sbcl-devel. +