On 24 June 2013 18:03, Teemu Likonen <tlikonen@...> wrote:
>> failed AVER: (NOT (EQL (FUNCTIONAL-KIND FUNCTIONAL) DELETED)) This
>> is probably a bug in SBCL itself.
>> I managed to shrink the relevant code quite a bit. As a shrunken
>> version it doesn't make sense but it should still compile. I'm using
>> SBCL 22.214.171.124-51bc001.
>> (defun test (string)
>> (cond ((every #'digit-char-p string)
>> ((some (lambda (c)
>> (digit-char-p c))
> More info: It seems that the AVER error is cause by this:
> (declaim (optimize (space 0)))
> With (space 1) it compiles.
Many, MANY thanks for the followup, and the original wonderfully
compact test case.
I managed to reproduce this. I did not look at the details yet (nor am
I likely to in the near future), but it seems that our MAYBE-INLINE is
We delete the optional dispatch while there is still a REF to a
DEFINED-FUN that has a references (without a REF) the optional
dispatch. This seems wrong -- but checking for that breaks elsewhere.
The optional dispatch also gets used in two components. This seems
iffy. Checking for that fixes the symptom, but I didn't check if it
breaks anything else...
diff --git a/src/compiler/ir1opt.lisp b/src/compiler/ir1opt.lisp
index 7f44b64..ecd913c 100644
@@ -1081,7 +1081,8 @@
(change-ref-leaf ref res))))
(let ((fun (defined-fun-functional leaf)))
(if (or (not fun)
- (and (eq inlinep :inline) (functional-kind fun)))
+ (and (eq inlinep :inline) (functional-kind fun))
+ (not (member (node-component call)
I'd need to page back more to convince myself this is the right thing,
though. I kind of suspect it is not.
Frankly, it seems to me that we're have a lot of special casing for
IMO dubious benefit due MAYBE-INLINE. Maybe we should remove it?
I'm leaving this here for someone else to ponder -- I'm unlikely to
return to the subject shortly unless I'm inspired to go on
MAYBE-INLINE killing spree some time next week.