SourceForge has been redesigned. Learn more.

sbcl-cvs-import Log

Commit Date  
[577487] by Alastair Bridgewater Alastair Bridgewater Build system refactoring

Moved flag processing as far "inward" as possible when dealing with
compile-stem, reducing the amount of redundant code for parsing out and
passing along boolean keywords based on the presence or absence of a
flag and eliminating some of the keyword arguments to compile-stem.

Added a "mode" parameter to compile-stem to enable determining the
correct compile-file function based on the combination of mode and
flags, further simplifying the interface.

Added new functions for determining the source and object pathnames
for a stem, fixing a longstanding KLUDGE in host-load-stem,
consolidating the three instances of code to compute an object pathname
and the two instances of code to compute a source pathname and
eliminating the rest of the keyword arguments to compile-stem.

2009-05-05 17:10:29 Tree
[80356c] by Nikodemus Siivola Nikodemus Siivola quiet WITH-TIMEOUT when used with constant EXPIRES argument

* Don't copy the body so as to avoid the compiler note for deleting
either leg, which happens when EXPIRES is a constant.

2009-05-05 10:53:16 Tree
[ef5fdd] by Nikodemus Siivola Nikodemus Siivola preserve non-toplevelness of macro subforms

* As per CLHS At least AND, OR, and COND where affected by
this. Reported by James Knight.

2009-05-05 09:41:24 Tree
[e7476d] by Alastair Bridgewater Alastair Bridgewater Fix bug 316325 (x86oid alien integer result truncation)

Change the parameters for :alien-rep alien-type-methods to include a
"CONTEXT" parameter to indicate if the type being sought is for a
function result representation. Ignore the new parameter on all
:alien-rep methods except for (integer :alien-rep).

Change (integer :alien-rep) to return an integer type the full width
of a machine register when asked for the function result

Condition out the (integer :naturalize-gen) method in
src/code/host-alieneval.lisp on x86oids (it's defined in

Change the type deriver for %alien-funcall to request the result
representation for the declared function result type.

In src/compiler/x86{,-64}/c-call.lisp, change the (integer
:naturalize-gen) alien-type-method to do field masking of unsigned
fields when needed.

Also in src/compiler/x86{,-64}/c-call.lisp, fix SIGN-EXTEND to not
lie to the compiler quite so badly about its argument types and add a
comment about a possible future optimization.

Add a test to tests/alien.impure.lisp, for completeness sake.

2009-05-04 23:09:02 Tree
[171e45] by Nikodemus Siivola Nikodemus Siivola faster array dimension typechecking code

* Put in an explicit ARRAY-HEADER-P, and short-circuit on its result
when possible, otherwise use the known presence or lack of header
to get dimensions more efficiently: using either %ARRAY-DIMENSION

2009-05-04 20:43:04 Tree
[277ef9] by Nikodemus Siivola Nikodemus Siivola open code ARRAY-RANK

* Faster multidimensional AREF if the array rank is not known
at compile-time.

2009-05-04 19:28:44 Tree
[9dcde1] by Nathan Froyd Nathan Froyd micro-optimize OUCH-READ-BUFFER

Remove an array bounds check and a couple of BOUNDP checks.

2009-05-01 21:01:57 Tree
[89f3ce] by Nathan Froyd Nathan Froyd eliminate *READ-BUFFER-LENGTH*

...take one down, commit the fix, 98 FIXMEs left in the source...

2009-05-01 20:29:39 Tree
[b402bb] by Nikodemus Siivola Nikodemus Siivola move the new PROGV tests to the right part of the file

* Oops.

2009-05-01 20:22:52 Tree
[3b7fca] by Nathan Froyd Nathan Froyd delete MERGE-BITS

Wasn't used anywhere; probably intended for bignum operations.

2009-05-01 18:17:46 Tree
[dad557] by Nikodemus Siivola Nikodemus Siivola various macro source locations were off-by-one due to #-sb-xc

* Thanks to Tobias Rittweiler -- now M-. DEFTRANSFORM, etc. work
better in Slime.

2009-05-01 12:03:54 Tree
[75f37c] by Nikodemus Siivola Nikodemus Siivola ABOUT-TO-MODIFY-SYMBOL-VALUE doesn't choke on FUNCTION subtypes

* Evaluating eg. a SET when the type of the variable as been
proclaimed to be a subtype of FUNCTION used to break, since
ABOUT-TO-MODIFY-SYMBOL-VALUE uses %%TYPEP to check the type, and
function subtypes are not normally acceptable type specifiers to

SBCL is, however, able to reason about such types, so we add an
optional STRICT argument to %%TYPEP defaulting to T, which
A-T-M-S-V give as NIL to allow checking of function subtypes.

Reported by Lorenz Mösenlechner.

2009-05-01 10:54:28 Tree
[4af56c] by Nikodemus Siivola Nikodemus Siivola fix bug 201, Incautious type inference from compound types

* Define LVAR-CONSERVATIVE-TYPE &co, which take into accound that a
function call can change the type of a cons or a non-simple array
without changing it's identity. Use this instead of LVAR-TYPE in
derive-type optimizers for CAR and CDR, and in the ARRAY-DIMENSIONS
transform. (There may be other places where it should be used as
well, but I could not find anything else just now.)

2009-05-01 10:35:43 Tree
[a71bcb] by Nikodemus Siivola Nikodemus Siivola disable address space randomization on Linux/x86-64

* At least some Red Hat versions do randomization on x86-64 as well,
whereas we used to assume only x86 had this "feature".

2009-05-01 10:30:50 Tree
[2b8c64] (sbcl.1.0.28sbcl_1_0_28) by Christophe Rhodes Christophe Rhodes

1.0.28: release, will be tagged as sbcl_1_0_28

2009-04-30 16:48:26 Tree
[72bd7d] by Gabor Melis Gabor Melis update platform table, credit me

2009-04-30 07:34:53 Tree
[932966] by Alastair Bridgewater Alastair Bridgewater Win32/Cygwin contrib build fix.

Recentish cygwin likes to have gcc as a symlink. SBCL can't handle
that, so, for cygwin only, fully dereference gcc if it's a symlink when
building contribs.

2009-04-28 16:02:13 Tree
[4f82cd] by Gabor Melis Gabor Melis fix RUN-PROGRAM on windows

Hopefully. There are mixed reports from users.

2009-04-27 20:26:10 Tree
[fdbabe] by Alastair Bridgewater Alastair Bridgewater Fix build on systems with "src" in the path. introduced an actual check that the path for all source
files is correctly externalized as an LPN at cold-init time. Due to a
longstanding bug in MAKE-FILE-INFO-NAMESTRING, not fixed with, it is possible for the system to create a pathname such as
Once the SYS: logical pathname translations are set up, this path is
not valid, causing a build failure. Fixed, at the cost of disallowing
paths in SYS:SRC that have a final directory of OUTPUT, not likely to
be an issue in practice.

2009-04-25 03:12:13 Tree
[51ef2f] by Richard M Kreuter Richard M Kreuter Fix the error signaled in bogus recursive READs.

* CHECK-FOR-RECURSIVE-READ signaled a READER-ERROR without supplying a
stream initarg.

2009-04-24 19:49:15 Tree
[fb2f16] by Christophe Rhodes Christophe Rhodes genesis fixes

make genesis of identical fasls produce identical cold cores.

4 messages follow:

documentation handling

CLISP supports documentation for packages now, so remove the read-time
conditional. However, don't try to use the documentation for the CL or
KEYWORD packages (as they come from the host directly)

LAYOUT clos hash values

Set them in cold-init using the target's RANDOM rather than in genesis
using the host's.

hash table traversal in genesis

MAPHASH will not give repeatable results in general, and certainly won't
between distinct implementations of hash tables. Sort the contents of
hash tables according to a predicate which completely orders the
contents. (This is mildly tricky for FDEFN names: we have to assume
that we are only dealing with names of the forms SYMBOL and (SETF

give smallvecs an initial element

Whoops. The smallvecs (representing the memory image of the core being
constructed) were being constructed without an initial-element. For the
most part this wouldn't matter, because it will (almost) all be
overwritten by the genesis process itself. The crux is in that
(almost), though; in some cases it matters, such as producing bogus
values for symbol tls slots. Mostly implementations seem to zero-fill
newly-constructed (unsigned-byte 8) arrays, but there seem to be some
circumstances under which CLISP will produce one with random data in

2009-04-24 15:56:10 Tree
[0408e5] by Christophe Rhodes Christophe Rhodes constant coalescing agreement fixes

Constant coalescing decisions, legitimately differing between different
hosts, can if not very careful propagate into the target, often through
vop-parse structures. Be explicit in which constants can be shared and
which shouldn't.

5 messages follow:

constant coalescing KLUDGE, part 1 [(any)]

The constant initforms for the vop-parse structure are evaluated on the
host; therefore, their coalescing is at the host's discretion. This
wouldn't matter except that (why?) vop-parse structures get dumped
at each vop definition. Make the coalescedness explicit.

constant coalescing KLUDGE, part 2: [(fixnumize n)]

The static function template for at least LENGTH (in subprim.lisp)
contains two instances of (FIXNUMIZE 2), which are coaelesced
differently on different host lisps. We can KLUDGE around this problem
(and gain a millimetric amount of efficiency, too!) by evaluating the
FIXNUMIZE calls at expansion time.

remove confusing code structure sharing from DEF-MOVE-IF

I can't actually see exactly where the code structure sharing happens
nor why it causes xc fasl contents to differ between hosts, but since
it makes the code clearer to rewrite the macro...

fix two separate issues in compiler/globaldb

One is a hash-table traversal issue; the other is coalescing of
constants. I *think* what's going on in the latter case is that there
are two separate ways that shared constants can happen. One is in the
dumping of objects which are EQUAL, where the compiler can dump a
reference to a previous object instead; the other is the dumping of a
single object with circularities, where a nil is dumped along with a
later instruction to backpatch the circularity in. We need to ensure a
deterministic cold-init-form, so that means we need to control the
coalescing in the _host_ compiler (because the cold-init-form is
generated from introspection), but of course we can't, so we COPY-TREE
instead, which will allow the xc to coalesce and will prevent the form
as compiled from sharing structure.

Static function template vop macro has a common subexpression, factored
out as new-ebp-ea.

2009-04-24 15:37:46 Tree
[7f6e75] by Christophe Rhodes Christophe Rhodes explicit determinism in the compiler

2 messages follow:

stable-sort the time specifications

Dunno if this is actually necessary for anything.

make unpacking and repacking happen in a determined order

The unpacked blocks were stuffed into a hash table and then maphashed
over; as in other cases, this is host-dependent. Use a list and pushnew

2009-04-24 15:08:28 Tree
[951044] by Christophe Rhodes Christophe Rhodes floating point implementation smoothing

To get floating point stuff exactly right, we should build a complete
IEEE float implementation to do calculations in for the cross-compiler.
Since that's not going to happen this millennium, instead try to be
careful when writing code that looks constant-foldable. Some other
fixups on the way...

6 messages follow:

fix load-time tests in src/code/pred

It turns out that #c(1.1 0) is not portable: it's a REAL in clisp and a
COMPLEX in sbcl.

begin work on floats

Floats Are Hard. The issue is that the host's float implementation,
even if it agrees with SBCL that SINGLE-FLOAT is IEEE single and
DOUBLE-FLOAT is IEEE double, may not match sbcl idiosyncracy for
idiosyncracy. For example, clisp doesn't support denormals, so its
LEAST-FOOATIVE-QUUXLE-FLOAT constants are very different from sbcl's:
and sbcl's can't even be represented within the host. Ugh.

Defining the print-related MIN-E constants is, however, easy enough.

comment (well, #!+long-float) out some floating point constants

The clauses in question were never taken absent #!+long-float anyway.

-0.0 is not portable: many lisps don't respect negative zeros

Use make-unportable-float instead, and hope that this doesn't matter
during cross-compilation...

host floating point differences

Not all lisps think (log 2d0 10d0) is the same. Compute it accurately

tentative attempt at smoothing over host floating point differences

Compute all the necessary constants as double-float bit patterns using

2009-04-24 14:41:54 Tree
[8f45dd] by Christophe Rhodes Christophe Rhodes host-invariant string constant coalescing

It took a little time to get right, but here's (I hope) invariant
constant string coalescing in the cross-file-compiler.

3 commit messages follow:

more invariant constant string coalescing

When dumping strings in cross-compilation, we always end up dumping as
base-string. That means we need to compare all strings of whatever
underlying array type for content equality, not just strings of the same
type. This shows up when dumping in the same file "BLOCK" and the value
of (symbol-name 'block) under CLISP, which dumps two separate values.

dumping string constants, the other half

Not only do we have to enter entries into the hash table with a known
element-type, we also have to retrieve them... bogosity finally picked
up by use of a CL symbol name (AND) in src/compiler/x86/insts.lisp...

further refinement on constant coalescing

Not only must we coalesce all kinds of strings at fasl dump time, we
must coalesce the constants in our TN representation while we're
compiling, otherwise we will get different lengths of constant vectors
for the same function depending on how many different string
representations there are in the host compiler.

2009-04-24 14:26:30 Tree
Older >