mirror of
git://git.code.sf.net/p/sbcl/sbcl
synced 2026-09-10 07:26:40 -04:00
f1e093e0f8
* Fix MISC.292: SET-DIFFERENCE does not preserve order;
* add commentaries;
* describe MISC.293 (PFD is incredibly good at finding rough
corners).
1259 lines
49 KiB
Plaintext
1259 lines
49 KiB
Plaintext
REPORTING BUGS
|
|
|
|
Bugs can be reported on the help mailing list
|
|
sbcl-help@lists.sourceforge.net
|
|
or on the development mailing list
|
|
sbcl-devel@lists.sourceforge.net
|
|
|
|
Please include enough information in a bug report that someone reading
|
|
it can reproduce the problem, i.e. don't write
|
|
Subject: apparent bug in PRINT-OBJECT (or *PRINT-LENGTH*?)
|
|
PRINT-OBJECT doesn't seem to work with *PRINT-LENGTH*. Is this a bug?
|
|
but instead
|
|
Subject: apparent bug in PRINT-OBJECT (or *PRINT-LENGTH*?)
|
|
In sbcl-1.2.3 running under OpenBSD 4.5 on my Alpha box, when
|
|
I compile and load the file
|
|
(DEFSTRUCT (FOO (:PRINT-OBJECT (LAMBDA (X Y)
|
|
(LET ((*PRINT-LENGTH* 4))
|
|
(PRINT X Y)))))
|
|
X Y)
|
|
then at the command line type
|
|
(MAKE-FOO)
|
|
the program loops endlessly instead of printing the object.
|
|
|
|
|
|
NOTES:
|
|
|
|
There is also some information on bugs in the manual page and
|
|
in the TODO file. Eventually more such information may move here.
|
|
|
|
The gaps in the number sequence belong to old bug descriptions which
|
|
have gone away (typically because they were fixed, but sometimes for
|
|
other reasons, e.g. because they were moved elsewhere).
|
|
|
|
|
|
2:
|
|
DEFSTRUCT almost certainly should overwrite the old LAYOUT information
|
|
instead of just punting when a contradictory structure definition
|
|
is loaded. As it is, if you redefine DEFSTRUCTs in a way which
|
|
changes their layout, you probably have to rebuild your entire
|
|
program, even if you know or guess enough about the internals of
|
|
SBCL to wager that this (undefined in ANSI) operation would be safe.
|
|
|
|
3: "type checking of structure slots"
|
|
a:
|
|
ANSI specifies that a type mismatch in a structure slot
|
|
initialization value should not cause a warning.
|
|
WORKAROUND:
|
|
This one might not be fixed for a while because while we're big
|
|
believers in ANSI compatibility and all, (1) there's no obvious
|
|
simple way to do it (short of disabling all warnings for type
|
|
mismatches everywhere), and (2) there's a good portable
|
|
workaround, and (3) by their own reasoning, it looks as though
|
|
ANSI may have gotten it wrong. ANSI justifies this specification
|
|
by saying
|
|
The restriction against issuing a warning for type mismatches
|
|
between a slot-initform and the corresponding slot's :TYPE
|
|
option is necessary because a slot-initform must be specified
|
|
in order to specify slot options; in some cases, no suitable
|
|
default may exist.
|
|
However, in SBCL (as in CMU CL or, for that matter, any compiler
|
|
which really understands Common Lisp types) a suitable default
|
|
does exist, in all cases, because the compiler understands the
|
|
concept of functions which never return (i.e. has return type NIL).
|
|
Thus, as a portable workaround, you can use a call to some
|
|
known-never-to-return function as the default. E.g.
|
|
(DEFSTRUCT FOO
|
|
(BAR (ERROR "missing :BAR argument")
|
|
:TYPE SOME-TYPE-TOO-HAIRY-TO-CONSTRUCT-AN-INSTANCE-OF))
|
|
or
|
|
(DECLAIM (FTYPE (FUNCTION () NIL) MISSING-ARG))
|
|
(DEFUN REQUIRED-ARG () ; workaround for SBCL non-ANSI slot init typing
|
|
(ERROR "missing required argument"))
|
|
(DEFSTRUCT FOO
|
|
(BAR (REQUIRED-ARG) :TYPE TRICKY-TYPE-OF-SOME-SORT)
|
|
(BLETCH (REQUIRED-ARG) :TYPE TRICKY-TYPE-OF-SOME-SORT)
|
|
(N-REFS-SO-FAR 0 :TYPE (INTEGER 0)))
|
|
Such code should compile without complaint and work correctly either
|
|
on SBCL or on any other completely compliant Common Lisp system.
|
|
|
|
b: &AUX argument in a boa-constructor without a default value means
|
|
"do not initilize this slot" and does not cause type error. But
|
|
an error may be signalled at read time and it would be good if
|
|
SBCL did it.
|
|
|
|
d: (fixed in 0.8.1.5)
|
|
|
|
7:
|
|
The "compiling top-level form:" output ought to be condensed.
|
|
Perhaps any number of such consecutive lines ought to turn into a
|
|
single "compiling top-level forms:" line.
|
|
|
|
11:
|
|
It would be nice if the
|
|
caught ERROR:
|
|
(during macroexpansion)
|
|
said what macroexpansion was at fault, e.g.
|
|
caught ERROR:
|
|
(during macroexpansion of IN-PACKAGE,
|
|
during macroexpansion of DEFFOO)
|
|
|
|
19:
|
|
(I *think* this is a bug. It certainly seems like strange behavior. But
|
|
the ANSI spec is scary, dark, and deep.. -- WHN)
|
|
(FORMAT NIL "~,1G" 1.4) => "1. "
|
|
(FORMAT NIL "~3,1G" 1.4) => "1. "
|
|
|
|
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.
|
|
|
|
32:
|
|
The printer doesn't report closures very well. This is true in
|
|
CMU CL 18b as well:
|
|
(PRINT #'CLASS-NAME)
|
|
gives
|
|
#<Closure Over Function "DEFUN STRUCTURE-SLOT-ACCESSOR" {134D1A1}>
|
|
It would be nice to make closures have a settable name slot,
|
|
and make things like DEFSTRUCT and FLET, which create closures,
|
|
set helpful values into this slot.
|
|
|
|
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.
|
|
|
|
35:
|
|
The compiler assumes that any time a function of declared FTYPE
|
|
doesn't signal an error, its arguments were of the declared type.
|
|
E.g. compiling and loading
|
|
(DECLAIM (OPTIMIZE (SAFETY 3)))
|
|
(DEFUN FACTORIAL (X) (GAMMA (1+ X)))
|
|
(DEFUN GAMMA (X) X)
|
|
(DECLAIM (FTYPE (FUNCTION (UNSIGNED-BYTE)) FACTORIAL))
|
|
(DEFUN FOO (X)
|
|
(COND ((> (FACTORIAL X) 1.0E6)
|
|
(FORMAT T "too big~%"))
|
|
((INTEGERP X)
|
|
(FORMAT T "exactly ~S~%" (FACTORIAL X)))
|
|
(T
|
|
(FORMAT T "approximately ~S~%" (FACTORIAL X)))))
|
|
then executing
|
|
(FOO 1.5)
|
|
will cause the INTEGERP case to be selected, giving bogus output a la
|
|
exactly 2.5
|
|
This violates the "declarations are assertions" principle.
|
|
According to the ANSI spec, in the section "System Class FUNCTION",
|
|
this is a case of "lying to the compiler", but the lying is done
|
|
by the code which calls FACTORIAL with non-UNSIGNED-BYTE arguments,
|
|
not by the unexpectedly general definition of FACTORIAL. In any case,
|
|
"declarations are assertions" means that lying to the compiler should
|
|
cause an error to be signalled, and should not cause a bogus
|
|
result to be returned. Thus, the compiler should not assume
|
|
that arbitrary functions check their argument types. (It might
|
|
make sense to add another flag (CHECKED?) to DEFKNOWN to
|
|
identify functions which *do* check their argument types.)
|
|
(Also, verify that the compiler handles declared function
|
|
return types as assertions.)
|
|
|
|
42:
|
|
The definitions of SIGCONTEXT-FLOAT-REGISTER and
|
|
%SET-SIGCONTEXT-FLOAT-REGISTER in x86-vm.lisp say they're not
|
|
supported on FreeBSD because the floating point state is not saved,
|
|
but at least as of FreeBSD 4.0, the floating point state *is* saved,
|
|
so they could be supported after all. Very likely
|
|
SIGCONTEXT-FLOATING-POINT-MODES could now be supported, too.
|
|
|
|
45:
|
|
a slew of floating-point-related errors reported by Peter Van Eynde
|
|
on July 25, 2000:
|
|
c: Many expressions generate floating infinity on x86/Linux:
|
|
(/ 1 0.0)
|
|
(/ 1 0.0d0)
|
|
(EXPT 10.0 1000)
|
|
(EXPT 10.0d0 1000)
|
|
PVE's regression tests want them to raise errors. sbcl-0.7.0.5
|
|
on x86/Linux generates the infinities instead. That might or
|
|
might not be conforming behavior, but it's also inconsistent,
|
|
which is almost certainly wrong. (Inconsistency: (/ 1 0.0)
|
|
should give the same result as (/ 1.0 0.0), but instead (/ 1 0.0)
|
|
generates SINGLE-FLOAT-POSITIVE-INFINITY and (/ 1.0 0.0)
|
|
signals an error.
|
|
d: (in section12.erg) various forms a la
|
|
(FLOAT 1 DOUBLE-FLOAT-EPSILON)
|
|
don't give the right behavior.
|
|
|
|
60:
|
|
The debugger LIST-LOCATIONS command doesn't work properly.
|
|
(How should it work properly?)
|
|
|
|
61:
|
|
Compiling and loading
|
|
(DEFUN FAIL (X) (THROW 'FAIL-TAG X))
|
|
(FAIL 12)
|
|
then requesting a BACKTRACE at the debugger prompt gives no information
|
|
about where in the user program the problem occurred.
|
|
|
|
64:
|
|
Using the pretty-printer from the command prompt gives funny
|
|
results, apparently because the pretty-printer doesn't know
|
|
about user's command input, including the user's carriage return
|
|
that the user, and therefore the pretty-printer thinks that
|
|
the new output block should start indented 2 or more characters
|
|
rightward of the correct location.
|
|
|
|
67:
|
|
As reported by Winton Davies on a CMU CL mailing list 2000-01-10,
|
|
and reported for SBCL by Martin Atzmueller 2000-10-20: (TRACE GETHASH)
|
|
crashes SBCL. In general tracing anything which is used in the
|
|
implementation of TRACE is likely to have the same problem.
|
|
|
|
78:
|
|
ANSI says in one place that type declarations can be abbreviated even
|
|
when the type name is not a symbol, e.g.
|
|
(DECLAIM ((VECTOR T) *FOOVECTOR*))
|
|
SBCL doesn't support this. But ANSI says in another place that this
|
|
isn't allowed. So it's not clear this is a bug after all. (See the
|
|
e-mail on cmucl-help@cons.org on 2001-01-16 and 2001-01-17 from WHN
|
|
and Pierre Mai.)
|
|
|
|
79:
|
|
as pointed out by Dan Barlow on sbcl-devel 2000-07-02:
|
|
The PICK-TEMPORARY-FILE-NAME utility used by LOAD-FOREIGN uses
|
|
an easily guessable temporary filename in a way which might open
|
|
applications using LOAD-FOREIGN to hijacking by malicious users
|
|
on the same machine. Incantations for doing this safely are
|
|
floating around the net in various "how to write secure programs
|
|
despite Unix" documents, and it would be good to (1) fix this in
|
|
LOAD-FOREIGN, and (2) hunt for any other code which uses temporary
|
|
files and make it share the same new safe logic.
|
|
|
|
(partially alleviated in sbcl-0.7.9.32 by a fix by Matthew Danish to
|
|
make the temporary filename less easily guessable)
|
|
|
|
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
|
|
the mean of the distribution can be systematically O(0.1%) wrong.
|
|
Just increasing R-I-E-B is probably not a good solution, since
|
|
it would decrease efficiency more than is probably necessary. Perhaps
|
|
using some sort of accept/reject method would be better.
|
|
|
|
85:
|
|
Internally the compiler sometimes evaluates
|
|
(sb-kernel:type/= (specifier-type '*) (specifier-type t))
|
|
(I stumbled across this when I added an
|
|
(assert (not (eq type1 *wild-type*)))
|
|
in the NAMED :SIMPLE-= type method.) '* isn't really a type, and
|
|
in a type context should probably be translated to T, and so it's
|
|
probably wrong to ask whether it's equal to the T type and then (using
|
|
the EQ type comparison in the NAMED :SIMPLE-= type method) return NIL.
|
|
(I haven't tried to investigate this bug enough to guess whether
|
|
there might be any user-level symptoms.)
|
|
|
|
In fact, the type system is likely to depend on this inequality not
|
|
holding... * is not equivalent to T in many cases, such as
|
|
(VECTOR *) /= (VECTOR T).
|
|
|
|
95:
|
|
The facility for dumping a running Lisp image to disk gets confused
|
|
when run without the PURIFY option, and creates an unnecessarily large
|
|
core file (apparently representing memory usage up to the previous
|
|
high-water mark). Moreover, when the file is loaded, it confuses the
|
|
GC, so that thereafter memory usage can never be reduced below that
|
|
level.
|
|
|
|
(As of 0.8.7.3 it's likely that the latter half of this bug is fixed.
|
|
The interaction between gencgc and the variables used by
|
|
save-lisp-and-die is still nonoptimal, though, so no respite from
|
|
big core files yet)
|
|
|
|
98:
|
|
In sbcl-0.6.11.41 (and in all earlier SBCL, and in CMU
|
|
CL), out-of-line structure slot setters are horribly inefficient
|
|
whenever the type of the slot is declared, because out-of-line
|
|
structure slot setters are implemented as closures to save space,
|
|
so the compiler doesn't compile the type test into code, but
|
|
instead just saves the type in a lexical closure and interprets it
|
|
at runtime.
|
|
To exercise the problem, compile and load
|
|
(cl:in-package :cl-user)
|
|
(defstruct foo
|
|
(bar (error "missing") :type bar))
|
|
(defvar *foo*)
|
|
(defun wastrel1 (x)
|
|
(loop (setf (foo-bar *foo*) x)))
|
|
(defstruct bar)
|
|
(defvar *bar* (make-bar))
|
|
(defvar *foo* (make-foo :bar *bar*))
|
|
(defvar *setf-foo-bar* #'(setf foo-bar))
|
|
(defun wastrel2 (x)
|
|
(loop (funcall *setf-foo-bar* x *foo*)))
|
|
then run (WASTREL1 *BAR*) or (WASTREL2 *BAR*), hit Ctrl-C, and
|
|
use BACKTRACE, to see it's spending all essentially all its time
|
|
in %TYPEP and VALUES-SPECIFIER-TYPE and so forth.
|
|
One possible solution would be simply to give up on
|
|
representing structure slot accessors as functions, and represent
|
|
them as macroexpansions instead. This can be inconvenient for users,
|
|
but it's not clear that it's worse than trying to help by expanding
|
|
into a horribly inefficient implementation.
|
|
As a workaround for the problem, #'(SETF FOO) expressions
|
|
can be replaced with (EFFICIENT-SETF-FUNCTION FOO), where
|
|
(defmacro efficient-setf-function (place-function-name)
|
|
(or #+sbcl (and (sb-int:info :function :accessor-for place-function-name)
|
|
;; a workaround for the problem, encouraging the
|
|
;; inline expansion of the structure accessor, so
|
|
;; that the compiler can optimize its type test
|
|
(let ((new-value (gensym "NEW-VALUE-"))
|
|
(structure-value (gensym "STRUCTURE-VALUE-")))
|
|
`(lambda (,new-value ,structure-value)
|
|
(setf (,place-function-name ,structure-value)
|
|
,new-value))))
|
|
;; no problem, can just use the ordinary expansion
|
|
`(function (setf ,place-function-name))))
|
|
|
|
100:
|
|
There's apparently a bug in CEILING optimization which caused
|
|
Douglas Crosher to patch the CMU CL version. Martin Atzmueller
|
|
applied the patches to SBCL and they didn't seem to cause problems
|
|
(as reported sbcl-devel 2001-05-04). However, since the patches
|
|
modify nontrivial code which was apparently written incorrectly
|
|
the first time around, until regression tests are written I'm not
|
|
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).
|
|
|
|
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
|
|
|
|
debugger invoked on a SB-INT:BUG in thread 5911:
|
|
failed AVER: "(SAP= CURRENT END)"
|
|
|
|
unless a GC has happened beforehand.
|
|
|
|
117:
|
|
When the compiler inline expands functions, it may be that different
|
|
kinds of return values are generated from different code branches.
|
|
E.g. an inline expansion of POSITION generates integer results
|
|
from one branch, and NIL results from another. When that inline
|
|
expansion is used in a context where only one of those results
|
|
is acceptable, e.g.
|
|
(defun foo (x)
|
|
(aref *a1* (position x *a2*)))
|
|
and the compiler can't prove that the unacceptable branch is
|
|
never taken, then bogus type mismatch warnings can be generated.
|
|
If you need to suppress the type mismatch warnings, you can
|
|
suppress the inline expansion,
|
|
(defun foo (x)
|
|
#+sbcl (declare (notinline position)) ; to suppress bug 117 bogowarnings
|
|
(aref *a1* (position x *a2*)))
|
|
or, sometimes, suppress them by declaring the result to be of an
|
|
appropriate type,
|
|
(defun foo (x)
|
|
(aref *a1* (the integer (position x *a2*))))
|
|
|
|
This is not a new compiler problem in 0.7.0, but the new compiler
|
|
transforms for FIND, POSITION, FIND-IF, and POSITION-IF make it
|
|
more conspicuous. If you don't need performance from these functions,
|
|
and the bogus warnings are a nuisance for you, you can return to
|
|
your pre-0.7.0 state of grace with
|
|
#+sbcl (declaim (notinline find position find-if position-if)) ; bug 117..
|
|
|
|
(see also bug 279)
|
|
|
|
118:
|
|
as reported by Eric Marsden on cmucl-imp@cons.org 2001-08-14:
|
|
(= (FLOAT 1 DOUBLE-FLOAT-EPSILON)
|
|
(+ (FLOAT 1 DOUBLE-FLOAT-EPSILON) DOUBLE-FLOAT-EPSILON)) => T
|
|
when of course it should be NIL. (He says it only fails for X86,
|
|
not SPARC; dunno about Alpha.)
|
|
|
|
Also, "the same problem exists for LONG-FLOAT-EPSILON,
|
|
DOUBLE-FLOAT-NEGATIVE-EPSILON, LONG-FLOAT-NEGATIVE-EPSILON (though
|
|
for the -negative- the + is replaced by a - in the test)."
|
|
|
|
Raymond Toy comments that this is tricky on the X86 since its FPU
|
|
uses 80-bit precision internally.
|
|
|
|
124:
|
|
As of version 0.pre7.14, SBCL's implementation of MACROLET makes
|
|
the entire lexical environment at the point of MACROLET available
|
|
in the bodies of the macroexpander functions. In particular, it
|
|
allows the function bodies (which run at compile time) to try to
|
|
access lexical variables (which are only defined at runtime).
|
|
It doesn't even issue a warning, which is bad.
|
|
|
|
The SBCL behavior arguably conforms to the ANSI spec (since the
|
|
spec says that the behavior is undefined, ergo anything conforms).
|
|
However, it would be better to issue a compile-time error.
|
|
Unfortunately I (WHN) don't see any simple way to detect this
|
|
condition in order to issue such an error, so for the meantime
|
|
SBCL just does this weird broken "conforming" thing.
|
|
|
|
The ANSI standard says, in the definition of the special operator
|
|
MACROLET,
|
|
The macro-expansion functions defined by MACROLET are defined
|
|
in the lexical environment in which the MACROLET form appears.
|
|
Declarations and MACROLET and SYMBOL-MACROLET definitions affect
|
|
the local macro definitions in a MACROLET, but the consequences
|
|
are undefined if the local macro definitions reference any
|
|
local variable or function bindings that are visible in that
|
|
lexical environment.
|
|
Then it seems to contradict itself by giving the example
|
|
(defun foo (x flag)
|
|
(macrolet ((fudge (z)
|
|
;The parameters x and flag are not accessible
|
|
; at this point; a reference to flag would be to
|
|
; the global variable of that name.
|
|
` (if flag (* ,z ,z) ,z)))
|
|
;The parameters x and flag are accessible here.
|
|
(+ x
|
|
(fudge x)
|
|
(fudge (+ x 1)))))
|
|
The comment "a reference to flag would be to the global variable
|
|
of the same name" sounds like good behavior for the system to have.
|
|
but actual specification quoted above says that the actual behavior
|
|
is undefined.
|
|
|
|
(Since 0.7.8.23 macroexpanders are defined in a restricted version
|
|
of the lexical environment, containing no lexical variables and
|
|
functions, which seems to conform to ANSI and CLtL2, but signalling
|
|
a STYLE-WARNING for references to variables similar to locals might
|
|
be a good thing.)
|
|
|
|
125:
|
|
(as reported by Gabe Garza on cmucl-help 2001-09-21)
|
|
(defvar *tmp* 3)
|
|
(defun test-pred (x y)
|
|
(eq x y))
|
|
(defun test-case ()
|
|
(let* ((x *tmp*)
|
|
(func (lambda () x)))
|
|
(print (eq func func))
|
|
(print (test-pred func func))
|
|
(delete func (list func))))
|
|
Now calling (TEST-CASE) gives output
|
|
NIL
|
|
NIL
|
|
(#<FUNCTION {500A9EF9}>)
|
|
Evidently Python thinks of the lambda as a code transformation so
|
|
much that it forgets that it's also an object.
|
|
|
|
135:
|
|
Ideally, uninterning a symbol would allow it, and its associated
|
|
FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However,
|
|
at least as of sbcl-0.7.0, this isn't the case. Information about
|
|
FDEFINITIONs and PROCLAIMed properties is stored in globaldb.lisp
|
|
essentially in ordinary (non-weak) hash tables keyed by symbols.
|
|
Thus, once a system has an entry in this system, it tends to live
|
|
forever, even when it is uninterned and all other references to it
|
|
are lost.
|
|
|
|
141: "pretty printing and backquote"
|
|
a.
|
|
* '``(FOO ,@',@S)
|
|
``(FOO SB-IMPL::BACKQ-COMMA-AT S)
|
|
|
|
c. (reported by Paul F. Dietz)
|
|
* '`(lambda ,x)
|
|
`(LAMBDA (SB-IMPL::BACKQ-COMMA X))
|
|
|
|
143:
|
|
(reported by Jesse Bouwman 2001-10-24 through the unfortunately
|
|
prominent SourceForge web/db bug tracking system, which is
|
|
unfortunately not a reliable way to get a timely response from
|
|
the SBCL maintainers)
|
|
In the course of trying to build a test case for an
|
|
application error, I encountered this behavior:
|
|
If you start up sbcl, and then lay on CTRL-C for a
|
|
minute or two, the lisp process will eventually say:
|
|
%PRIMITIVE HALT called; the party is over.
|
|
and throw you into the monitor. If I start up lisp,
|
|
attach to the process with strace, and then do the same
|
|
(abusive) thing, I get instead:
|
|
access failure in heap page not marked as write-protected
|
|
and the monitor again. I don't know enough to have the
|
|
faintest idea of what is going on here.
|
|
This is with sbcl 6.12, uname -a reports:
|
|
Linux prep 2.2.19 #4 SMP Tue Apr 24 13:59:52 CDT 2001 i686 unknown
|
|
I (WHN) have verified that the same thing occurs on sbcl-0.pre7.141
|
|
under OpenBSD 2.9 on my X86 laptop. Do be patient when you try it:
|
|
it took more than two minutes (but less than five) for me.
|
|
|
|
145:
|
|
a.
|
|
ANSI allows types `(COMPLEX ,FOO) to use very hairy values for
|
|
FOO, e.g. (COMPLEX (AND REAL (SATISFIES ODDP))). The old CMU CL
|
|
COMPLEX implementation didn't deal with this, and hasn't been
|
|
upgraded to do so. (This doesn't seem to be a high priority
|
|
conformance problem, since seems hard to construct useful code
|
|
where it matters.)
|
|
|
|
b. (fixed in 0.8.3.43)
|
|
|
|
146:
|
|
Floating point errors are reported poorly. E.g. on x86 OpenBSD
|
|
with sbcl-0.7.1,
|
|
* (expt 2.0 12777)
|
|
debugger invoked on condition of type SB-KERNEL:FLOATING-POINT-EXCEPTION:
|
|
An arithmetic error SB-KERNEL:FLOATING-POINT-EXCEPTION was signalled.
|
|
No traps are enabled? How can this be?
|
|
It should be possible to be much more specific (overflow, division
|
|
by zero, etc.) and of course the "How can this be?" should be fixable.
|
|
|
|
See also bugs #45.c and #183
|
|
|
|
162:
|
|
(reported by Robert E. Brown 2002-04-16)
|
|
When a function is called with too few arguments, causing the
|
|
debugger to be entered, the uninitialized slots in the bad call frame
|
|
seem to cause GCish problems, being interpreted as tagged data even
|
|
though they're not. In particular, executing ROOM in the
|
|
debugger at that point causes AVER failures:
|
|
* (machine-type)
|
|
"X86"
|
|
* (lisp-implementation-version)
|
|
"0.7.2.12"
|
|
* (typep 10)
|
|
...
|
|
0] (room)
|
|
...
|
|
failed AVER: "(SAP= CURRENT END)"
|
|
(Christophe Rhodes reports that this doesn't occur on the SPARC, which
|
|
isn't too surprising since there are many differences in stack
|
|
implementation and GC conservatism between the X86 and other ports.)
|
|
|
|
This is probably the same bug as 216
|
|
|
|
167:
|
|
In sbcl-0.7.3.11, compiling the (illegal) code
|
|
(in-package :cl-user)
|
|
(defmethod prove ((uustk uustk))
|
|
(zap ((frob () nil))
|
|
(frob)))
|
|
gives the (not terribly clear) error message
|
|
; caught ERROR:
|
|
; (during macroexpansion of (DEFMETHOD PROVE ...))
|
|
; can't get template for (FROB NIL NIL)
|
|
The problem seems to be that the code walker used by the DEFMETHOD
|
|
macro is unhappy with the illegal syntax in the method body, and
|
|
is giving an unclear error message.
|
|
|
|
173:
|
|
The compiler sometimes tries to constant-fold expressions before
|
|
it checks to see whether they can be reached. This can lead to
|
|
bogus warnings about errors in the constant folding, e.g. in code
|
|
like
|
|
(WHEN X
|
|
(WRITE-STRING (> X 0) "+" "0"))
|
|
compiled in a context where the compiler can prove that X is NIL,
|
|
and the compiler complains that (> X 0) causes a type error because
|
|
NIL isn't a valid argument to #'>. Until sbcl-0.7.4.10 or so this
|
|
caused a full WARNING, which made the bug really annoying because then
|
|
COMPILE and COMPILE-FILE returned FAILURE-P=T for perfectly legal
|
|
code. Since then the warning has been downgraded to STYLE-WARNING,
|
|
so it's still a bug but at least it's a little less annoying.
|
|
|
|
183: "IEEE floating point issues"
|
|
Even where floating point handling is being dealt with relatively
|
|
well (as of sbcl-0.7.5, on sparc/sunos and alpha; see bug #146), the
|
|
accrued-exceptions and current-exceptions part of the fp control
|
|
word don't seem to bear much relation to reality. E.g. on
|
|
SPARC/SunOS:
|
|
* (/ 1.0 0.0)
|
|
|
|
debugger invoked on condition of type DIVISION-BY-ZERO:
|
|
arithmetic error DIVISION-BY-ZERO signalled
|
|
0] (sb-vm::get-floating-point-modes)
|
|
|
|
(:TRAPS (:OVERFLOW :INVALID :DIVIDE-BY-ZERO)
|
|
:ROUNDING-MODE :NEAREST
|
|
:CURRENT-EXCEPTIONS NIL
|
|
:ACCRUED-EXCEPTIONS (:INEXACT)
|
|
:FAST-MODE NIL)
|
|
0] abort
|
|
* (sb-vm::get-floating-point-modes)
|
|
(:TRAPS (:OVERFLOW :INVALID :DIVIDE-BY-ZERO)
|
|
:ROUNDING-MODE :NEAREST
|
|
:CURRENT-EXCEPTIONS (:INEXACT)
|
|
:ACCRUED-EXCEPTIONS (:INEXACT)
|
|
:FAST-MODE NIL)
|
|
|
|
188: "compiler performance fiasco involving type inference and UNION-TYPE"
|
|
(time (compile
|
|
nil
|
|
'(lambda ()
|
|
(declare (optimize (safety 3)))
|
|
(declare (optimize (compilation-speed 2)))
|
|
(declare (optimize (speed 1) (debug 1) (space 1)))
|
|
(let ((start 4))
|
|
(declare (type (integer 0) start))
|
|
(print (incf start 22))
|
|
(print (incf start 26))
|
|
(print (incf start 28)))
|
|
(let ((start 6))
|
|
(declare (type (integer 0) start))
|
|
(print (incf start 22))
|
|
(print (incf start 26)))
|
|
(let ((start 10))
|
|
(declare (type (integer 0) start))
|
|
(print (incf start 22))
|
|
(print (incf start 26))))))
|
|
|
|
This example could be solved with clever enough constraint
|
|
propagation or with SSA, but consider
|
|
|
|
(let ((x 0))
|
|
(loop (incf x 2)))
|
|
|
|
The careful type of X is {2k} :-(. Is it really important to be
|
|
able to work with unions of many intervals?
|
|
|
|
191: "Miscellaneous PCL deficiencies"
|
|
(reported by Alexey Dejneka sbcl-devel 2002-08-04)
|
|
a. DEFCLASS does not inform the compiler about generated
|
|
functions. Compiling a file with
|
|
(DEFCLASS A-CLASS ()
|
|
((A-CLASS-X)))
|
|
(DEFUN A-CLASS-X (A)
|
|
(WITH-SLOTS (A-CLASS-X) A
|
|
A-CLASS-X))
|
|
results in a STYLE-WARNING:
|
|
undefined-function
|
|
SB-SLOT-ACCESSOR-NAME::|COMMON-LISP-USER A-CLASS-X slot READER|
|
|
|
|
APD's fix for this was checked in to sbcl-0.7.6.20, but Pierre
|
|
Mai points out that the declamation of functions is in fact
|
|
incorrect in some cases (most notably for structure
|
|
classes). This means that at present erroneous attempts to use
|
|
WITH-SLOTS and the like on classes with metaclass STRUCTURE-CLASS
|
|
won't get the corresponding STYLE-WARNING.
|
|
c. (fixed in 0.8.4.23)
|
|
|
|
201: "Incautious type inference from compound types"
|
|
a. (reported by APD sbcl-devel 2002-09-17)
|
|
(DEFUN FOO (X)
|
|
(LET ((Y (CAR (THE (CONS INTEGER *) X))))
|
|
(SETF (CAR X) NIL)
|
|
(FORMAT NIL "~S IS ~S, Y = ~S"
|
|
(CAR X)
|
|
(TYPECASE (CAR X)
|
|
(INTEGER 'INTEGER)
|
|
(T '(NOT INTEGER)))
|
|
Y)))
|
|
|
|
(FOO ' (1 . 2)) => "NIL IS INTEGER, Y = 1"
|
|
|
|
b.
|
|
* (defun foo (x)
|
|
(declare (type (array * (4 4)) x))
|
|
(let ((y x))
|
|
(setq x (make-array '(4 4)))
|
|
(adjust-array y '(3 5))
|
|
(= (array-dimension y 0) (eval `(array-dimension ,y 0)))))
|
|
FOO
|
|
* (foo (make-array '(4 4) :adjustable t))
|
|
NIL
|
|
|
|
205: "environment issues in cross compiler"
|
|
(These bugs have no impact on user code, but should be fixed or
|
|
documented.)
|
|
a. Macroexpanders introduced with MACROLET are defined in the null
|
|
lexical environment.
|
|
b. The body of (EVAL-WHEN (:COMPILE-TOPLEVEL) ...) is evaluated in
|
|
the null lexical environment.
|
|
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
|
|
effort to produce hash-codes that are well distributed
|
|
within the range of non-negative fixnums". But
|
|
(let ((hits (make-hash-table)))
|
|
(dotimes (i 16)
|
|
(dotimes (j 16)
|
|
(let* ((ij (cons i j))
|
|
(newlist (push ij (gethash (sxhash ij) hits))))
|
|
(when (cdr newlist)
|
|
(format t "~&collision: ~S~%" newlist))))))
|
|
reports lots of collisions in sbcl-0.7.8. A stronger MIX function
|
|
would be an obvious way of fix. Maybe it would be acceptably efficient
|
|
to redo MIX using a lookup into a 256-entry s-box containing
|
|
29-bit pseudorandom numbers?
|
|
|
|
211: "keywords processing"
|
|
a. :ALLOW-OTHER-KEYS T should allow a function to receive an odd
|
|
number of keyword arguments.
|
|
e. Compiling
|
|
|
|
(flet ((foo (&key y) (list y)))
|
|
(list (foo :y 1 :y 2)))
|
|
|
|
issues confusing message
|
|
|
|
; in: LAMBDA NIL
|
|
; (FOO :Y 1 :Y 2)
|
|
;
|
|
; caught STYLE-WARNING:
|
|
; The variable #:G15 is defined but never used.
|
|
|
|
212: "Sequence functions and circular arguments"
|
|
COERCE, MERGE and CONCATENATE go into an infinite loop when given
|
|
circular arguments; it would be good for the user if they could be
|
|
given an error instead (ANSI 17.1.1 allows this behaviour on the part
|
|
of the implementation, as conforming code cannot give non-proper
|
|
sequences to these functions. MAP also has this problem (and
|
|
solution), though arguably the convenience of being able to do
|
|
(MAP 'LIST '+ FOO '#1=(1 . #1#))
|
|
might be classed as more important (though signalling an error when
|
|
all of the arguments are circular is probably desireable).
|
|
|
|
213: "Sequence functions and type checking"
|
|
a. (fixed in 0.8.4.36)
|
|
b. MAP, when given a type argument that is SUBTYPEP LIST, does not
|
|
check that it will return a sequence of the given type. Fixing
|
|
it along the same lines as the others (cf. work done around
|
|
sbcl-0.7.8.45) is possible, but doing so efficiently didn't look
|
|
entirely straightforward.
|
|
c. All of these functions will silently accept a type of the form
|
|
(CONS INTEGER *)
|
|
whether or not the return value is of this type. This is
|
|
probably permitted by ANSI (see "Exceptional Situations" under
|
|
ANSI MAKE-SEQUENCE), but the DERIVE-TYPE mechanism does not
|
|
know about this escape clause, so code of the form
|
|
(INTEGERP (CAR (MAKE-SEQUENCE '(CONS INTEGER *) 2)))
|
|
can erroneously return T.
|
|
|
|
215: ":TEST-NOT handling by functions"
|
|
a. FIND and POSITION currently signal errors when given non-NIL for
|
|
both their :TEST and (deprecated) :TEST-NOT arguments, but by
|
|
ANSI 17.2 "the consequences are unspecified", which by ANSI 1.4.2
|
|
means that the effect is "unpredictable but harmless". It's not
|
|
clear what that actually means; it may preclude conforming
|
|
implementations from signalling errors.
|
|
b. COUNT, REMOVE and the like give priority to a :TEST-NOT argument
|
|
when conflict occurs. As a quality of implementation issue, it
|
|
might be preferable to treat :TEST and :TEST-NOT as being in some
|
|
sense the same &KEY, and effectively take the first test function in
|
|
the argument list.
|
|
c. Again, a quality of implementation issue: it would be good to issue a
|
|
STYLE-WARNING at compile-time for calls with :TEST-NOT, and a
|
|
WARNING for calls with both :TEST and :TEST-NOT; possibly this
|
|
latter should be WARNed about at execute-time too.
|
|
|
|
216: "debugger confused by frames with invalid number of arguments"
|
|
In sbcl-0.7.8.51, executing e.g. (VECTOR-PUSH-EXTEND T), BACKTRACE, Q
|
|
leaves the system confused, enough so that (QUIT) no longer works.
|
|
It's as though the process of working with the uninitialized slot in
|
|
the bad VECTOR-PUSH-EXTEND frame causes GC problems, though that may
|
|
not be the actual problem. (CMU CL 18c doesn't have problems with this.)
|
|
|
|
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))))
|
|
|
|
#<FUN-TYPE (FUNCTION (BASE-CHAR) *)>
|
|
|
|
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.)
|
|
|
|
233: bugs in constraint propagation
|
|
b.
|
|
(declaim (optimize (speed 2) (safety 3)))
|
|
(defun foo (x y)
|
|
(if (typep (prog1 x (setq x y)) 'double-float)
|
|
(+ x 1d0)
|
|
(+ x 2)))
|
|
(foo 1d0 5) => segmentation violation
|
|
|
|
235: "type system and inline expansion"
|
|
a.
|
|
(declaim (ftype (function (cons) number) acc))
|
|
(declaim (inline acc))
|
|
(defun acc (c)
|
|
(the number (car c)))
|
|
|
|
(defun foo (x y)
|
|
(values (locally (declare (optimize (safety 0)))
|
|
(acc x))
|
|
(locally (declare (optimize (safety 3)))
|
|
(acc y))))
|
|
|
|
(foo '(nil) '(t)) => NIL, T.
|
|
|
|
237: "Environment arguments to type functions"
|
|
a. Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and
|
|
UPGRADED-COMPLEX-PART-TYPE now have an optional environment
|
|
argument, but they ignore it completely. This is almost
|
|
certainly not correct.
|
|
b. Also, the compiler's optimizers for TYPEP have not been informed
|
|
about the new argument; consequently, they will not transform
|
|
calls of the form (TYPEP 1 'INTEGER NIL), even though this is
|
|
just as optimizeable as (TYPEP 1 'INTEGER).
|
|
|
|
238: "REPL compiler overenthusiasm for CLOS code"
|
|
From the REPL,
|
|
* (defclass foo () ())
|
|
* (defmethod bar ((x foo) (foo foo)) (call-next-method))
|
|
causes approximately 100 lines of code deletion notes. Some
|
|
discussion on this issue happened under the title 'Three "interesting"
|
|
bugs in PCL', resulting in a fix for this oververbosity from the
|
|
compiler proper; however, the problem persists in the interactor
|
|
because the notion of original source is not preserved: for the
|
|
compiler, the original source of the above expression is (DEFMETHOD
|
|
BAR ((X FOO) (FOO FOO)) (CALL-NEXT-METHOD)), while by the time the
|
|
compiler gets its hands on the code needing compilation from the REPL,
|
|
it has been macroexpanded several times.
|
|
|
|
A symptom of the same underlying problem, reported by Tony Martinez:
|
|
* (handler-case
|
|
(with-input-from-string (*query-io* " no")
|
|
(yes-or-no-p))
|
|
(simple-type-error () 'error))
|
|
; in: LAMBDA NIL
|
|
; (SB-KERNEL:FLOAT-WAIT)
|
|
;
|
|
; note: deleting unreachable code
|
|
; compilation unit finished
|
|
; printed 1 note
|
|
|
|
241: "DEFCLASS mysteriously remembers uninterned accessor names."
|
|
(from tonyms on #lisp IRC 2003-02-25)
|
|
In sbcl-0.7.12.55, typing
|
|
(defclass foo () ((bar :accessor foo-bar)))
|
|
(profile foo-bar)
|
|
(unintern 'foo-bar)
|
|
(defclass foo () ((bar :accessor foo-bar)))
|
|
gives the error message
|
|
"#:FOO-BAR already names an ordinary function or a macro."
|
|
So it's somehow checking the uninterned old accessor name instead
|
|
of the new requested accessor name, which seems broken to me (WHN).
|
|
|
|
242: "WRITE-SEQUENCE suboptimality"
|
|
(observed from clx performance)
|
|
In sbcl-0.7.13, WRITE-SEQUENCE of a sequence of type
|
|
(SIMPLE-ARRAY (UNSIGNED-BYTE 8) (*)) on a stream with element-type
|
|
(UNSIGNED-BYTE 8) will write to the stream one byte at a time,
|
|
rather than writing the sequence in one go, leading to severe
|
|
performance degradation.
|
|
|
|
243: "STYLE-WARNING overenthusiasm for unused variables"
|
|
(observed from clx compilation)
|
|
In sbcl-0.7.14, in the presence of the macros
|
|
(DEFMACRO FOO (X) `(BAR ,X))
|
|
(DEFMACRO BAR (X) (DECLARE (IGNORABLE X)) 'NIL)
|
|
somewhat surprising style warnings are emitted for
|
|
(COMPILE NIL '(LAMBDA (Y) (FOO Y))):
|
|
; in: LAMBDA (Y)
|
|
; (LAMBDA (Y) (FOO Y))
|
|
;
|
|
; caught STYLE-WARNING:
|
|
; The variable Y is defined but never used.
|
|
|
|
245: bugs in disassembler
|
|
a. On X86 an immediate operand for IMUL is printed incorrectly.
|
|
b. On X86 operand size prefix is not recognized.
|
|
|
|
251:
|
|
(defun foo (&key (a :x))
|
|
(declare (fixnum a))
|
|
a)
|
|
|
|
does not cause a warning. (BTW: old SBCL issued a warning, but for a
|
|
function, which was never called!)
|
|
|
|
256:
|
|
Compiler does not emit warnings for
|
|
|
|
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)))
|
|
|
|
c. (lambda (x)
|
|
(declare (optimize (debug 0)))
|
|
(declare (type vector x))
|
|
(list (fill-pointer x)
|
|
(svref x 1)))
|
|
|
|
257:
|
|
Complex array type does not have corresponding type specifier.
|
|
|
|
This is a problem because the compiler emits optimization notes when
|
|
you use a non-simple array, and without a type specifier for hairy
|
|
array types, there's no good way to tell it you're doing it
|
|
intentionally so that it should shut up and just compile the code.
|
|
|
|
Another problem is confusing error message "asserted type ARRAY
|
|
conflicts with derived type (VALUES SIMPLE-VECTOR &OPTIONAL)" during
|
|
compiling (LAMBDA (V) (VALUES (SVREF V 0) (VECTOR-POP V))).
|
|
|
|
The last problem is that when type assertions are converted to type
|
|
checks, types are represented with type specifiers, so we could lose
|
|
complex attribute. (Now this is probably not important, because
|
|
currently checks for complex arrays seem to be performed by
|
|
callees.)
|
|
|
|
259:
|
|
(compile nil '(lambda () (aref (make-array 0) 0))) compiles without
|
|
warning. Analogous cases with the index and length being equal and
|
|
greater than 0 are warned for; the problem here seems to be that the
|
|
type required for an array reference of this type is (INTEGER 0 (0))
|
|
which is canonicalized to NIL.
|
|
|
|
260:
|
|
a.
|
|
(let* ((s (gensym))
|
|
(t1 (specifier-type s)))
|
|
(eval `(defstruct ,s))
|
|
(type= t1 (specifier-type s)))
|
|
=> NIL, NIL
|
|
|
|
(fixed in 0.8.1.24)
|
|
|
|
b. The same for CSUBTYPEP.
|
|
|
|
262: "yet another bug in inline expansion of local functions"
|
|
Compiler fails on
|
|
|
|
(defun foo (x y)
|
|
(declare (integer x y))
|
|
(+ (block nil
|
|
(flet ((xyz (u)
|
|
(declare (integer u))
|
|
(if (> (1+ (the unsigned-byte u)) 0)
|
|
(+ 1 u)
|
|
(return (+ 38 (cos (/ u 78)))))))
|
|
(declare (inline xyz))
|
|
(return-from foo
|
|
(* (funcall (eval #'xyz) x)
|
|
(if (> x 30)
|
|
(funcall (if (> x 5) #'xyz #'identity)
|
|
(+ x 13))
|
|
38)))))
|
|
(sin (* x y))))
|
|
|
|
Urgh... It's time to write IR1-copier.
|
|
|
|
266:
|
|
David Lichteblau provided (sbcl-devel 2003-06-01) a patch to fix
|
|
behaviour of streams with element-type (SIGNED-BYTE 8). The patch
|
|
looks reasonable, if not obviously correct; however, it caused the
|
|
PPC/Linux port to segfault during warm-init while loading
|
|
src/pcl/std-class.fasl. A workaround patch was made, but it would
|
|
be nice to understand why the first patch caused problems, and to
|
|
fix the cause if possible.
|
|
|
|
268: "wrong free declaration scope"
|
|
The following code must signal type error:
|
|
|
|
(locally (declare (optimize (safety 3)))
|
|
(flet ((foo (x &optional (y (car x)))
|
|
(declare (optimize (safety 0)))
|
|
(list x y)))
|
|
(funcall (eval #'foo) 1)))
|
|
|
|
269:
|
|
SCALE-FLOAT should accept any integer for its second argument.
|
|
|
|
270:
|
|
In the following function constraint propagator optimizes nothing:
|
|
|
|
(defun foo (x)
|
|
(declare (integer x))
|
|
(declare (optimize speed))
|
|
(typecase x
|
|
(fixnum "hala")
|
|
(fixnum "buba")
|
|
(bignum "hip")
|
|
(t "zuz")))
|
|
|
|
273:
|
|
Compilation of the following two forms causes "X is unbound" error:
|
|
|
|
(symbol-macrolet ((x pi))
|
|
(macrolet ((foo (y) (+ x y)))
|
|
(declaim (inline bar))
|
|
(defun bar (z)
|
|
(* z (foo 4)))))
|
|
(defun quux (z)
|
|
(bar z))
|
|
|
|
(See (COERCE (CDR X) 'FUNCTION) in IR1-CONVERT-INLINE-LAMBDA.)
|
|
|
|
274:
|
|
CLHS says that type declaration of a symbol macro should not affect
|
|
its expansion, but in SBCL it does. (If you like magic and want to
|
|
fix it, don't forget to change all uses of MACROEXPAND to
|
|
MACROEXPAND*.)
|
|
|
|
275:
|
|
The following code (taken from CLOCC) takes a lot of time to compile:
|
|
|
|
(defun foo (n)
|
|
(declare (type (integer 0 #.large-constant) n))
|
|
(expt 1/10 n))
|
|
|
|
(fixed in 0.8.2.51, but a test case would be good)
|
|
|
|
276:
|
|
(defmethod fee ((x fixnum))
|
|
(setq x (/ x 2))
|
|
x)
|
|
(fee 1) => type error
|
|
|
|
(taken from CLOCC)
|
|
|
|
278:
|
|
a.
|
|
(defun foo ()
|
|
(declare (optimize speed))
|
|
(loop for i of-type (integer 0) from 0 by 2 below 10
|
|
collect i))
|
|
|
|
uses generic arithmetic.
|
|
|
|
b. (fixed in 0.8.3.6)
|
|
|
|
279: type propagation error -- correctly inferred type goes astray?
|
|
In sbcl-0.8.3 and sbcl-0.8.1.47, the warning
|
|
The binding of ABS-FOO is a (VALUES (INTEGER 0 0)
|
|
&OPTIONAL), not a (INTEGER 1 536870911)
|
|
is emitted when compiling this file:
|
|
(declaim (ftype (function ((integer 0 #.most-positive-fixnum))
|
|
(integer #.most-negative-fixnum 0))
|
|
foo))
|
|
(defun foo (x)
|
|
(- x))
|
|
(defun bar (x)
|
|
(let* (;; Uncomment this for a type mismatch warning indicating
|
|
;; that the type of (FOO X) is correctly understood.
|
|
#+nil (fs-foo (float-sign (foo x)))
|
|
;; Uncomment this for a type mismatch warning
|
|
;; indicating that the type of (ABS (FOO X)) is
|
|
;; correctly understood.
|
|
#+nil (fs-abs-foo (float-sign (abs (foo x))))
|
|
;; something wrong with this one though
|
|
(abs-foo (abs (foo x))))
|
|
(declare (type (integer 1 100) abs-foo))
|
|
(print abs-foo)))
|
|
|
|
(see also bug 117)
|
|
|
|
280: bogus WARNING about duplicate function definition
|
|
In sbcl-0.8.3 and sbcl-0.8.1.47, if BS.MIN is defined inline,
|
|
e.g. by
|
|
(declaim (inline bs.min))
|
|
(defun bs.min (bases) nil)
|
|
before compiling the file below, the compiler warns
|
|
Duplicate definition for BS.MIN found in one static
|
|
unit (usually a file).
|
|
when compiling
|
|
(declaim (special *minus* *plus* *stagnant*))
|
|
(defun b.*.min (&optional (x () xp) (y () yp) &rest rest)
|
|
(bs.min avec))
|
|
(define-compiler-macro b.*.min (&rest rest)
|
|
`(bs.min ,@rest))
|
|
(defun afish-d-rbd (pd)
|
|
(if *stagnant*
|
|
(b.*.min (foo-d-rbd *stagnant*))
|
|
(multiple-value-bind (reduce-fn initial-value)
|
|
(etypecase pd
|
|
(list (values #'bs.min 0))
|
|
(vector (values #'bs.min *plus*)))
|
|
(let ((cv-ks (cv (kpd.ks pd))))
|
|
(funcall reduce-fn d-rbds)))))
|
|
(defun bfish-d-rbd (pd)
|
|
(if *stagnant*
|
|
(b.*.min (foo-d-rbd *stagnant*))
|
|
(multiple-value-bind (reduce-fn initial-value)
|
|
(etypecase pd
|
|
(list (values #'bs.min *minus*))
|
|
(vector (values #'bs.min 0)))
|
|
(let ((cv-ks (cv (kpd.ks pd))))
|
|
(funcall reduce-fn d-rbds)))))
|
|
|
|
281: COMPUTE-EFFECTIVE-METHOD error signalling.
|
|
(slightly obscured by a non-0 default value for
|
|
SB-PCL::*MAX-EMF-PRECOMPUTE-METHODS*)
|
|
It would be natural for COMPUTE-EFFECTIVE-METHOD to signal errors
|
|
when it finds a method with invalid qualifiers. However, it
|
|
shouldn't signal errors when any such methods are not applicable to
|
|
the particular call being evaluated, and certainly it shouldn't when
|
|
simply precomputing effective methods that may never be called.
|
|
(setf sb-pcl::*max-emf-precompute-methods* 0)
|
|
(defgeneric foo (x)
|
|
(:method-combination +)
|
|
(:method ((x symbol)) 1)
|
|
(:method + ((x number)) x))
|
|
(foo 1) -> ERROR, but should simply return 1
|
|
|
|
The issue seems to be that construction of a discriminating function
|
|
calls COMPUTE-EFFECTIVE-METHOD with methods that are not all applicable.
|
|
|
|
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
|
|
bug instead of creating new ones
|
|
|
|
localtime() - called for timezone calculations in code/time.lisp
|
|
|
|
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
|
|
parts of the system. See doc/internals/notes/threading-specials
|
|
|
|
286: "recursive known functions"
|
|
Self-call recognition conflicts with known function
|
|
recognition. Currently cross compiler and target COMPILE do not
|
|
recognize recursion, and in target compiler it can be disabled. We
|
|
can always disable it for known functions with RECURSIVE attribute,
|
|
but there remains a possibility of a function with a
|
|
(tail)-recursive simplification pass and transforms/VOPs for base
|
|
cases.
|
|
|
|
287: PPC/Linux miscompilation or corruption in first GC
|
|
When the runtime is compiled with -O3 on certain PPC/Linux machines, a
|
|
segmentation fault is reported at the point of first triggered GC,
|
|
during the compilation of DEFSTRUCT WRAPPER. As a temporary workaround,
|
|
the runtime is no longer compiled with -O3 on PPC/Linux, but it is likely
|
|
that this merely obscures, not solves, the underlying problem; as and when
|
|
underlying problems are fixed, it would be worth trying again to provoke
|
|
this problem.
|
|
|
|
288: fundamental cross-compilation issues (from old UGLINESS file)
|
|
Using host floating point numbers to represent target floating point
|
|
numbers, or host characters to represent target characters, is
|
|
theoretically shaky. (The characters are OK as long as the characters
|
|
are in the ANSI-guaranteed character set, though, so they aren't a
|
|
real problem as long as the sources don't need anything but that;
|
|
the floats are a real problem.)
|
|
|
|
289: "type checking and source-transforms"
|
|
a.
|
|
(block nil (let () (funcall #'+ (eval 'nil) (eval '1) (return :good))))
|
|
signals type error.
|
|
|
|
Our policy is to check argument types at the moment of a call. It
|
|
disagrees with ANSI, which says that type assertions are put
|
|
immediately onto argument expressions, but is easier to implement in
|
|
IR1 and is more compatible to type inference, inline expansion,
|
|
etc. IR1-transforms automatically keep this policy, but source
|
|
transforms for associative functions (such as +), being applied
|
|
during IR1-convertion, do not. It may be tolerable for direct calls
|
|
(+ x y z), but for (FUNCALL #'+ x y z) it is non-conformant.
|
|
|
|
b. Another aspect of this problem is efficiency. [x y + z +]
|
|
requires less registers than [x y z + +]. This transformation is
|
|
currently performed with source transforms, but it would be good to
|
|
also perform it in IR1 optimization phase.
|
|
|
|
290: Alpha floating point and denormalized traps
|
|
In SBCL 0.8.3.6x on the alpha, we work around what appears to be a
|
|
hardware or kernel deficiency: the status of the enable/disable
|
|
denormalized-float traps bit seems to be ambiguous; by the time we
|
|
get to os_restore_fp_control after a trap, denormalized traps seem
|
|
to be enabled. Since we don't want a trap every time someone uses a
|
|
denormalized float, in general, we mask out that bit when we restore
|
|
the control word; however, this clobbers any change the user might
|
|
have made.
|
|
|
|
296:
|
|
(reported by Adam Warner, sbcl-devel 2003-09-23)
|
|
|
|
The --load toplevel argument does not perform any sanitization of its
|
|
argument. As a result, files with Lisp pathname pattern characters
|
|
(#\* or #\?, for instance) or quotation marks can cause the system
|
|
to perform arbitrary behaviour.
|
|
|
|
297:
|
|
LOOP with non-constant arithmetic step clauses suffers from overzealous
|
|
type constraint: code of the form
|
|
(loop for d of-type double-float from 0d0 to 10d0 by x collect d)
|
|
compiles to a type restriction on X of (AND DOUBLE-FLOAT (REAL
|
|
(0))). However, an integral value of X should be legal, because
|
|
successive adds of integers to double-floats produces double-floats,
|
|
so none of the type restrictions in the code is violated.
|
|
|
|
300: (reported by Peter Graves) Function PEEK-CHAR checks PEEK-TYPE
|
|
argument type only after having read a character. This is caused
|
|
with EXPLICIT-CHECK attribute in DEFKNOWN. The similar problem
|
|
exists with =, /=, <, >, <=, >=. They were fixed, but it is probably
|
|
less error prone to have EXPLICIT-CHECK be a local declaration,
|
|
being put into the definition, instead of an attribute being kept in
|
|
a separate file; maybe also put it into SB-EXT?
|
|
|
|
301: ARRAY-SIMPLE-=-TYPE-METHOD breaks on corner cases which can arise
|
|
in NOTE-ASSUMED-TYPES
|
|
In sbcl-0.8.7.32, compiling the file
|
|
(defun foo (x y)
|
|
(declare (type integer x))
|
|
(declare (type (vector (or hash-table bit)) y))
|
|
(bletch 2 y))
|
|
(defun bar (x y)
|
|
(declare (type integer x))
|
|
(declare (type (simple-array base (2)) y))
|
|
(bletch 1 y))
|
|
gives the error
|
|
failed AVER: "(NOT (AND (NOT EQUALP) CERTAINP))"
|
|
|
|
302: Undefined type messes up DATA-VECTOR-REF expansion.
|
|
Compiling this file
|
|
(defun dis (s ei x y)
|
|
(declare (type (simple-array function (2)) s) (type ei ei))
|
|
(funcall (aref s ei) x y))
|
|
on sbcl-0.8.7.36/X86/Linux causes a BUG to be signalled:
|
|
full call to SB-KERNEL:DATA-VECTOR-REF
|
|
|
|
303: "nonlinear LVARs" (aka MISC.293)
|
|
(defun buu (x)
|
|
(multiple-value-call #'list
|
|
(block foo
|
|
(multiple-value-prog1
|
|
(eval '(values :a :b :c))
|
|
(catch 'bar
|
|
(if (> x 0)
|
|
(return-from foo
|
|
(eval `(if (> ,x 1)
|
|
1
|
|
(throw 'bar (values 3 4)))))))))))
|
|
|
|
(BUU 1) returns garbage.
|
|
|
|
The problem is that both EVALs write to the same LVAR.
|