sbcl Log


Commit Date  
[8cc24b] (sbcl_1_0_45) by Juho Snellman Juho Snellman

1.0.45: will be tagged as sbcl_1_0_45

2010-12-06 01:25:53 Tree
[6501a9] by Christophe Rhodes Christophe Rhodes

1.0.44.36: test case for bug #681092

From the bug report. Also remove needless quotes in some test names.

2010-11-27 21:08:53 Tree
[55383e] by Alastair Bridgewater Alastair Bridgewater

1.0.44.35: Use DX-FLET instead of FLET in WITHOUT-{INTERRUPTS,GCING}.

* With the local functions declared to be DYNAMIC-EXTENT, the
new d-x closure analysis can elide the value cells involved
entirely.

* This fixes lp#674458 (introduced in 1.0.44.16).

2010-11-27 03:02:03 Tree
[a5bbce] by Alastair Bridgewater Alastair Bridgewater

1.0.44.34: gtn: KLUDGE the lambda-var assignment to not break tail-calls.

* As an utter KLUDGE, when assigning TNs for closed-over lambda
variables with implicit value-cells, make the TNs component-live
instead of physenv-live. This prevents any possible problems with
the new physenv introduced by a tail-call overwriting the storage
for the variable.

2010-11-27 03:01:50 Tree
[818b7d] by Alastair Bridgewater Alastair Bridgewater

1.0.44.33: ir2tran: Correctly set up d-x closure values for tail-local-calls.

* Tail-local-call re-uses the current frame. It therefore needs to
use the old-fp value from the current frame in EMIT-PSETQ-MOVES.

* "implicit" value cells need to use the /current/ frame pointer in
EMIT-PSETQ-MOVES to correctly initialize the closure.

* Therefore: Add a new &optional argument to EMIT-PSETQ-MOVES for
the frame-pointer to be used in closure initialization.

* This fixes the obvious part of lp#681092, but unless there is a
guarantee that the stack slots used for the "implicit" value cells
remain unused in the tail-called function then all this does is drive
the bug to become more subtle.

2010-11-27 03:01:34 Tree
[c4776b] by Nikodemus Siivola Nikodemus Siivola

1.0.44.32: better error reporting for malformed RESTART-CASE clauses

Detect missing lambda-lists.

...and missing -o to canonicalize-whitespace.

2010-11-19 10:57:30 Tree
[03b0b9] by Nikodemus Siivola Nikodemus Siivola

1.0.44.31: fix canonicalize-whitespace

...missing -o from last commit.

2010-11-19 10:54:44 Tree
[f741a1] by Nikodemus Siivola Nikodemus Siivola

1.0.44.30: don't canonicalize whitespace in ASDF

ASDF isn't that tightly coupled to SBCL anymore -- and munging
the whitespace there just makes comparing SBCL and upstream ASDFs
more difficult.

2010-11-19 10:13:40 Tree
[b29df9] by Nikodemus Siivola Nikodemus Siivola

1.0.44.29: full warnings for duplicate CASE keys during SBCL build

...and fix the issue revealed.

Thanks to Cyrus Harmon for the heads-up.

2010-11-18 13:52:06 Tree
[caab09] by Nikodemus Siivola Nikodemus Siivola

1.0.44.28: allow approximating unions of numeric types

(dummy commit: change described here happened in the last commit really,
but the commit message was subtly wrong and missed the version number)

* Binding *APPROXIMATE-NUMERIC-UNIONS* does that. It must be bound
only by callers of TYPE-UNION that know what they want -- in general

(OR (INTEGER 1 2) (INTEGER 4 4)) => (INTEGER 1 4)

is wrong, as (NOT (INTEGER 1 4)) doesn't include 3. But in special cases
like deriving the return type of a function it can be done.

* Rename MAKE-CANONICAL-UNION-TYPE MAKE-DERIVED-UNION-TYPE, and bind *A-N-U*
there if we start accumulating an overly large union of numeric types.
Definition of "overly large" can be adjusted via
*DERIVED-NUMERIC-UNION-COMPLEXITY-LIMIT*.

* Fixes lp#309448 and the recent compiler performance regression due
to new CONCATENATE deftransform as reported on sbcl-devel.

2010-11-18 12:02:45 Tree
[dbe82b] by Nikodemus Siivola Nikodemus Siivola

allow approximating unions of numeric types

* Binding *APPROXIMATE-NUMERIC-UNIONS* does that. It must be bound
only by callers of TYPE-UNION that know what they want -- in general

(OR (INTEGER 1 2) (INTEGER 3 4)) => (INTEGER 1 4)

is wrong, as (NOT (INTEGER 1 4)) doesn't include 3. But in special cases
like deriving the return type of a function it can be done.

* Rename MAKE-CANONICAL-UNION-TYPE MAKE-DERIVED-UNION-TYPE, and bind *A-N-U*
there if we start accumulating an overly large union of numeric types.
Definition of "overly large" can be adjusted via
*DERIVED-NUMERIC-UNION-COMPLEXITY-LIMIT*.

* Fixes lp#309448 and the recent compiler performance regression due
to new CONCATENATE deftransform as reported on sbcl-devel.

2010-11-18 11:28:46 Tree
[0aad67] by Nikodemus Siivola Nikodemus Siivola

1.0.44.27: update ASDF to 2.010

2010-11-18 10:06:30 Tree
[4fa1c7] by Nikodemus Siivola Nikodemus Siivola

1.0.44.26: more nuanced deprecation framework

DEFINE-DEPRECATED-FUNCTION is the new one-stop shop for the "common"
case of deprecating a function in favor of another one.

...in cases where it is not sufficient, call DEPRECATION-WARNING or
DEPRECATION-ERROR directly from the compiler or other place.

Three stages: :EARLY signals a compile-time style-warning, :LATE
signals a compile-time full warning, :FINAL a compile-time full
warning and a run-time error.

(This is based on the assumption that this is both a sufficient and
desirably nuanced taxonomy -- if more or less is wanted, changing
this later is easy enough.)

SB-EXT:DEPRECATION-CONDITION is the base class of all deprecation
warnings and errors, but it isn't yet documented: once we have a
concensus of sorts on a deprecation protocol/schedule, I will write
the appropriate bits in the manual.

Everything that previously had a deprecation warning is now in :LATE
stage, except for INSTANCE-LAMBDA which is now in :FINAL stage.

2010-11-16 18:18:03 Tree
[ea6c9e] by Nikodemus Siivola Nikodemus Siivola

1.0.44.25: don't put function leaves into the source-path when a name is available

#<SB-C::DEFINED-FUN ...> in compiler notes is a bit hard to read, not
to mention obscure.

2010-11-16 17:57:45 Tree
[8ae420] by Nikodemus Siivola Nikodemus Siivola

1.0.44.24: tweak CAREFUL-EXPAND-MACRO

Don't resignal warnings and style-warnings -- aside from the CMUCL
cross-compiler KLUDGEry. They tend to be intentionally signalled by macro
and compiler-macro authors, and the additional wrapper-text provided by the
resignaling mostly just obfuscates the actual message.

That leaves errors (and the aforementioned KLUDGE.)

For these, less parentheses, more whitespace -- specifically, leave space
around the actual warning/error message, instead of crowding in with the
parenthetical remarks.

2010-11-16 15:17:10 Tree
[8f2883] by Nikodemus Siivola Nikodemus Siivola

1.0.44.23: replace %METHOD-NAME and %METHOD-LAMBDA-LIST decls with special variables

This not only simplifies PCL code, but fixes a long-standing MOP-bug
and actually gives us SB-PCL:SLOW-METHOD frames in the backtraces.

Previously a fairly trivial MAKE-METHOD-LAMBDA method was enough
to cause

(defmethod foo (x) (return-from foo t))

to break, as MAKE-METHOD-LAMBDA-INTERNAL no longer found the %METHOD-NAME
declaration in the expected place, and hence was unable to add the block
name.

2010-11-15 17:43:37 Tree
[8e7660] by Nikodemus Siivola Nikodemus Siivola

1.0.44.22: NEWS entry left out from 1.0.44.21.

EOM.

2010-11-10 17:52:05 Tree
[9df2ab] by Nikodemus Siivola Nikodemus Siivola

1.0.44.21: expand ~ in pathnames

~/... => (:ABSOLUTE :HOME ...)

~user/... => (:ABSOLUTE (:HOME "user") ...)

Translation back to NAMESTRING reinstates the tilde, so we retain
read/write consistency.

NATIVE-NAMESTRING is responsible for getting the actual full path
to specified home directory.

This late resolution is necessary to have (open "~/foo") and
(open #p"~/foo") open the same file in compiled code -- regardless
of who compiled the file.

Tilde is treated specially only at the start of the first directory
component: it doesn't need to be escaped anywhere else. After trying
out the various options (escape everywhere, escape in directory
components, escape at the start of directory components, escape at
the start of all components) this seemed both least intrusive and
least ambiguous when documented -- not to mention most backwards
compatible.

Currently escaping the tilde does not work on Windows, but this is due to
current general inability to escape the first directory component on
Windows, since \\ is used also as a directory separator for non-native
pathnames as well. See lp#673625. Test-case added for this.

(:HOME "user") also doesn't work on Windows, which is documented
in the manual.

2010-11-10 17:49:30 Tree
[110ebc] by Nikodemus Siivola Nikodemus Siivola

1.0.44.20: clarify meaning of make.sh --dynamic-space-size option

EOM.

2010-11-10 17:39:25 Tree
[9e83e3] by Alastair Bridgewater Alastair Bridgewater

1.0.44.19: NEWS: Updates for changes starting at 1.0.44.6.

* EOM.

2010-11-09 19:46:49 Tree
[6e1eec] by Alastair Bridgewater Alastair Bridgewater

1.0.44.18: physenvanal: When checking closure-DXness, handle XEPs reasonably.

* In ANALYZE-INDIRECT-LAMBDA-VARS, treat functionals as being DX if
either they are marked as being DX or they have a FUNCTIONAL-ENTRY-FUN
that is marked as being DX.

* This extends the existing logic to allow functions with XEPs (those
functions callable via the full-call convention) to use the
ANCESTOR-FRAME optimizations.

2010-11-09 19:46:33 Tree
[97f956] by Alastair Bridgewater Alastair Bridgewater

1.0.44.17: ir1: Declare UNWIND-PROTECT cleanup functions to be dynamic-extent.

* Since we now have the analysis to do the right thing
for these functions, why not take advantage of it?

2010-11-09 19:45:50 Tree
[48646d] by Alastair Bridgewater Alastair Bridgewater

1.0.44.16: ir2tran: Don't try to stack-allocate VALUE-CELLs.

* Explicit VALUE-CELLs are only used if a closure that refers
to a mutable LAMBDA-VAR has indefinite extent, implying that the
reference itself has indefinite extent. In such cases, dynamic
extent allocation of the VALUE-CELL is contraindicated.

* Remove most of the logic from EMIT-MAKE-VALUE-CELL, leaving
only the statistics-tracking (EVENT) and the VOP emission,
forcing the new VALUE-CELL to be heap-allocated.

2010-11-09 19:45:36 Tree
[c097df] by Alastair Bridgewater Alastair Bridgewater

1.0.44.15: ir2: Skip value-cell allocation where possible.

* Expose the new ANCESTOR-FRAME VOPs in package-data.lisp-expr.

* When creating TNs for closed-over LAMBDA-VARs with "implicit"
VALUE-CELLs, force the TNs to be allocated on the control-stack,
and to be live over the entire extent of the PHYSENV.

* When translating a REF or SET node for such LAMBDA-VARs from
a NODE in a CLAMBDA with a different PHYSENV, use the new VOPs to
access the LAMBDA-VAR.

* When setting up a closure for such LAMBDA-VARs from a NODE in
a CLAMBDA with the same PHYSENV as the variable, use the new
CLOSURE-INIT-FROM-FP VOP to stash the frame pointer instead of a
VALUE-CELL or the current value of the variable.

* When setting up the closure environment for a local-call that
closes over such a LAMBDA-VAR, and the call is being made from a
NODE in a CLAMBDA with the same PHYSENV as the variable, store the
current frame-pointer instead of a VALUE-CELL or the current value
of the variable.

2010-11-09 19:45:23 Tree
[2c3112] by Alastair Bridgewater Alastair Bridgewater

1.0.44.14: x86-64: Implement ANCESTOR-FRAME VOPs.

* This is the x86-64 version of the "implicit" VALUE-CELL access
for DYNAMIC-EXTENT closures.

2010-11-09 19:45:09 Tree
Older >