sbcl Log

Commit Date  
[e7b2c5] (4.4 kB) by Nikodemus Siivola Nikodemus Siivola

more robust backtraces for syscalls on x86

* new optimization policy: ALIEN-FUNCALL-SAVES-FP-AND-PC Set to 3 for
self-build on x86 to get reliable more backtraces there, and 0 for
other platforms. (1 matches the old SPEED <= DEBUG behaviour.)

* When using a saved FP, and an interrupt context has a bogus
FP, assume it is an interrupted syscall frame.

2011-08-01 13:46:26 View
[545fde] (4.3 kB) by Nikodemus Siivola Nikodemus Siivola fix make-host-2.lisp from

THAT was not supposed to go in. Grr. Sorry.

2010-10-07 16:49:30 View
[975352] (4.3 kB) by Nikodemus Siivola Nikodemus Siivola differentiate cross-compiler output from target and host

No difference in the end-product, but seeing "x-compiling" in
build-logs makes them easier to read for slow people like me.

That is:

* while building the xc-host messages are from the host compiler.
If the host happens to be SBCL, that means:

; compiling (DEFUN FOO ...)

* while building the target:

; x-compiling (DEFUN FOO ...)

* while building CLOS and contribs on target:

; compiling (DEFUN FOO ...)

2010-10-07 16:40:47 View
[41248d] (4.3 kB) by Nathan Froyd Nathan Froyd fix clisp build for ppc

LP #576587, thanks to Josh Elsasser for the patch.

2010-05-10 00:39:12 View
[77bf76] (4.1 kB) by Christophe Rhodes Christophe Rhodes Fewer XC/reader-conditional confusions
Inspired by Josh Elasser (sbcl-devel 2008-08-29), write code
that tries to be clever about reader conditionals in the
cross-compiler, in order to point out when a mistake is likely.
... and fix the extra buglet that this reveals.

2008-09-04 13:04:45 View
[682203] (4.0 kB) by Nikodemus Siivola Nikodemus Siivola refactor stack allocation decisions

* Remove SB-C::STACK-ALLOCATE-* policies.

is true (the default), with the following exceptions:

** Value cells are not stack allocated.

** Vectors that may be longer then a single page are stack
allocated only in SAFETY 0 policies.

* New declaration: SB-INT:TRULY-DYNAMIC-EXTENT. Always stack-allocates,
regardless of SB-EXT:*STACK-ALLOCATE-DYNAMIC-EXTENT*. Also causes stack
allocation of value cells and potentially large vectors.

Used exclusively inside SBCL.

* Move STACK-ALLOCATE-RESULT optimizers from backends to

* Documentation.

2008-07-30 17:58:39 View
[496071] (4.1 kB) by pkhuong pkhuong Remove global STACK-ALLOCATE-VALUE-CELLS proclamation in make-host-2.lisp

* introduced a new optimization quality to control the stack-allocation
of value cells. All the places in the code base where it was needed now declare
it explicitly.

2008-05-16 18:55:00 View
[a572ab] (4.2 kB) by Nikodemus Siivola Nikodemus Siivola workaround for bug 419

* Require an explicit SB-C::STACK-ALLOCATE-VALUE-CELLS optimize
declaration before stack allocating value cells to prevent
returning garbage values from hairy user code.

2008-05-12 14:12:42 View
[89987c] (4.1 kB) by Christophe Rhodes Christophe Rhodes
Beginnings of a Win32 merge.
... rearrange the build scripts to use input from files rather
than <<HERE documents.
... (no other changes; just working to get the meaty changes
isolated from the fluff)

2005-12-29 16:08:31 View

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks