Christophe Rhodes wrote:
> william.newman@... (William Harold Newman) writes:
>> Until then, committers please avoid committing anything complicated or
>> non-urgent, and everyone else, extra testing and bug reports are
>> especially appreciated.
> There is a current problem (a regression from the last release) in
> building on architectures where with-pinned-objects boils down to
> without-gcing -- that is, all non-x86ish ports. (The problem appears
> first in genesis, which is slightly surprising; we try to take the
> warm-symbol of a descriptor that appears to be for a
> There also seems to be a regression in slot-valueish computation (as
> well as the unwanted compiler notes discussed earlier): something
> appears to go wrong and an attempt is made to get the slot vector of a
> built-in class (see <http://paste.lisp.org/display/44850> for some
> If we're not close to resolving these issues by the end of the
> weekend, I suspect that I'll be tempted to revert the commits that are
> the proximate causes of these problems.
I'm going to be working on these over the weekend, and don't foresee
any particular problems in solving them.
I also have one other compiler bug fix incoming: the actual bug has been
present since 0.9.17.5, but the new MEMBER and ASSOC transformations
cause it be be encountered with greatly increased likelyhood.
(compile nil '(lambda (x y)
(declare (optimize sb-c::preserve-single-use-debug-variables))
(if (block nil
(return (member x y))))
(error "~a" y))))
The bug is in the lexenv frobbing in TRANSFORM-CALL: *LEXENV* needs
to be bound to the new combination-lexenv around the IR1-CONVERT-INLINE-LAMBDA,
since otherwise the new CALL nodes generated for optional / varargs entry points
will not be consistent.