gmane.lisp.steel-bank.devel

"Failed AVER": A bug in SBCL?

Teemu Likonen — 2013-06-17T16:31:37

Hello

I noticed a strange error message when I tried to compile a code of
mine. I don't understand much so I probably can't write useful bug
reports. Here's the error message:


    failed AVER: (NOT (EQL (FUNCTIONAL-KIND FUNCTIONAL) DELETED)) This
    is probably a bug in SBCL itself. (Alternatively, SBCL might have
    been corrupted by bad user code, e.g. by an undefined Lisp operation
    like (FMAKUNBOUND 'COMPILE), or by stray pointers from alien code or
    from unsafe Lisp code; or there might be a bug in the OS or hardware
    that SBCL is running on.) If it seems to be a bug in SBCL itself,
    the maintainers would like to know about it. Bug reports are welcome
    on the SBCL mailing lists, which you can find at
    <http://sbcl.sourceforge.net/>. [Condition of type SB-INT:BUG]


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
1.1.8.30-51bc001.


    (defun test (string)
      (cond ((every #'digit-char-p string)
             nil)
            ((some (lambda (c)
                     (digit-char-p c))
                   string))))
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev_______________________________________________
Sbcl-devel mailing list
Sbcl-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

Regression tests for SBCL with cl-test-grid

Jan Moringen — 2013-06-15T14:18:54

Hi,

I'm working on automated regression tests for SBCL using cl-test-grid.
Most things worked very well so far - thank you for the great project. I
am writing to ask two questions.

First, should I get everything working, would the use of your
infrastructure (result storage and result namespace) be acceptable? For
now, I set up the result storage id "sbcl" and user email
"sbcl-maintainers". I expect about three test results each day: one test
run on each of three machines. If that was currently unacceptable, would
donations help?

The second question is about a problem with the result upload: after a
complete test run, the upload of log files to the blob store starts but
fails at some point. I observed two failure modes:

1. With vanilla cl-test-grid, the upload failed due to a
"connection reset by peer". I suspected this to be due to some
app engine quota violation since the upload was probably more
than 20 MB within one minute. I tried to work around this by
waiting between log file uploads.
2. This slowed-down version behaves similarly but fails with a
"broken pipe".

A full log of the second failure mode is available [1] (Warning: ~ 40 MB
of text; search for "Broken pipe"). Do you have an idea about what may
be going wrong?

Many thanks in advance and kind regards,
Jan

[1] https://ci.cor-lab.org/job/sbcl-master-test-grid/label=ubuntu_quantal_64bit/lastBuild/consoleFull

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev

Yet another rule-based peephole optimizer attempt (along question)

Douglas Katzman — 2013-06-12T05:51:33

Hi developers,

I've looked at previous starts on this idea (notably Jonathan Smith's plus
some chatter between Nathan and Nikodemus > .5 decades ago), and I've
thought to take up the cause again.  I have a working piece of code that
operates in "finalize-segment" after having buffered up all instructions in
their abstract (not machine-encoded) format, with TNs as their operands.
 This works nicely modulo a bug in my understanding of TN liveness.

To motivate this discussion I'll show two examples of what the thing should
be capable of doing, subject to an assumption (presently false) that its
def/use tracking at the register level is correct:

* (disassemble '(lambda (a) (setf (svref a 3) #xf00d)))
;; with assembler debugging
< at > 15 "eliminate tmp reg for CMP"
  (MOV RDX QWORD PTR [RCX-7]),(MOV RAX 6),(CMP RDX RAX) -> ((MOV RAX 6)
(CMP QWORD PTR [RCX-7] RAX))
< at > 18 "Imm-to-mem move"
  (MOV RDX 122906),(MOV QWORD PTR [RBX+RAX*4+1] RDX) -> ((MOV QWORD PTR
[RBX+RAX*4+1] 122906))

(I see it missed that it could use an immediate 6, subject to RAX being
dead, for an operand in an instruction that was already edited one time)
Despite that, it makes mincemeat out of OPTIMIZATIONS item #35:

* (disassemble '(lambda (a i) (aref (the simple-vector a) i)))
;; with assembler debugging
< at > 17 "eliminate tmp reg for CMP"
  (MOV RBX RDI),(CMP RBX 0) -> ((CMP RDI 0))
< at > 19 "eliminate tmp reg for CMP"
  (MOV RBX RDI),(CMP RBX QWORD PTR [+#S(SB-C:FIXUP :NAME NIL :FLAVOR
CODE-OBJECT :OFFSET L1)]) -> ((CMP RDI QWORD PTR [+#S(SB-C:FIXUP :NAME NIL
:FLAVOR CODE-OBJECT :OFFSET L1)]))
< at > 20 "Relocate BREAK"
  (JMP LE L2),(MOV RAX Const5),(BREAK),(.TRAP-INFO 10 31 RDI RAX) -> ((JMP
NLE L3))
< at > 17 "Signed compares -> unsigned compare"
  (CMP RDI 0),(JMP L L3),(CMP RDI QWORD PTR [+#S(SB-C:FIXUP :NAME NIL
:FLAVOR CODE-OBJECT :OFFSET L1)]),(JMP NLE L3) -> ((CMP RDI QWORD PTR
[+#S(SB-C:FIXUP :NAME NIL :FLAVOR CODE-OBJECT :OFFSET L1)]) (JMP A L3))
< at > 19 "eliminate tmp reg for CMP"
  (MOV RBX QWORD PTR [RDX-7]),(MOV RSI RDI),(CMP RBX RSI) -> ((MOV RSI RDI)
(CMP QWORD PTR [RDX-7] RSI))
< at > 19 "eliminate tmp reg for vector index in safe SVREF"
  (MOV RSI RDI),(CMP QWORD PTR [RDX-7] RSI),(JMP BE L4),(MOV RDX QWORD PTR
[RDX+RDI*4+1]) -> ((CMP QWORD PTR [RDX-7] RDI) (JMP BE L4) (MOV RDX QWORD
PTR [RDX+RSI*4+1]))
< at > 17 "vector bound check subsumes INDEX type check"
  (CMP RDI QWORD PTR [+#S(SB-C:FIXUP :NAME NIL :FLAVOR CODE-OBJECT :OFFSET
L1)]),(JMP A L3),(CMP QWORD PTR [RDX-7] RDI),(JMP BE L4) -> ((CMP QWORD PTR
[RDX-7] RDI) (JMP BE L4))

Here's the fly in the ointment -

My first cut performed optimizations in a vacuum, without knowing IR2 stuff.
It was highly conservative, examining only straight-line code; and as well
as being unmaintainable and inflexible crud, could not perform interesting
transformations.
For what little it was worth, this could operate on anybody's x86 assembly
source code doing only very trivial rewrites such as
 "AND RAX,imm;AND RAX,other-imm" -> "AND RAX,(AND imm other-imm)"

My next approach looked for TNs that could be deleted with impunity since
SBCL's abstract assembly code (not machine-encoded) has the TNs.  When we
find for example "MOV t1, [mem]; MOV t2, t1" with no other apparent use of
t1 then we can maybe substitute "MOV t2, [mem]"
This approach scanned the assembly segment for references to context TNs
(the fragment of code in which replacement occurs) outside that context.
This admits more optimization but is still wrong because the helpful MOVE
function elides references to TNs in the same register, so despite that you
see no uses of a TN by looking at instructions, that's not necessarily true.

My third way got rid of the scanning logic that didn't work, and avails
itself of the TN-READS slot but:
 (1) it doesn't work because code emitters can use MAKE-RANDOM-TN to put
something in an instruction that is unreflective of what the VOP operands
were,
AND
 (2) I thought I understood TN-REFs but I don't.

My sense was that sufficed to ensure that each TN in the instructions being
edited (the context), to be a candidate for elision, must have exactly one
read ref and that the ref is also in the context, except that some ref can
read a TN from anywhere else. (This glosses over some points but that's the
general idea)  These conditions holding, all the above replacements that
say "eliminate ..." would be admissible.

I suspect that a hybrid approach, with some way of detecting random TN
creation will win, and ultimately be inordinately simpler than abstract
interpretation and register tracing.  I preserved my hack to keep
"do-nothing" TN moves just to see them in case of need; then they're
deleted when calling the real assembler.

Anyway, my changes to 'assem.lisp' are significantly less invasive than one
would think; the hair is in other files plus some ancillary cleanups.  All
the EMIT-foo macros just buffer stuff up, and then FINALIZE-SEGMENT calls
the rewriter which then calls back to the real EMIT encoders.
Nothing in the scheduling assembler logic is altered - this could be a
pre-pass to instruction-level scheduling if so desired. (They're at
different levels of abstraction)

On the plus side, SBCL is able to compile itself and pass all tests in the
following regimes:
- the target-feature to bring in vm-specific rewriting rules is absent
(i.e. the few hooks in 'assem' are in, the new rule driving loop is in, but
the rewriter has nothing to do).
- the rules are present but those which use the mythical TN-ELIDABLE-P test
are disabled
These give confidence that the assembler still works.

I'm certainly happy to compose a patch of everything, especially since at
least a few parts of it are factorable out such as adding an assembler
directive for '.trap-info' rather than having to reverse engineer that
"BYTE;BYTE;BYTE..." was perhaps a list of SC-OFFSETs for a trap handler.
This allows for example possible elision of a register-register move for a
register holding
the bound of a vector - you have to alter the trap data too. (Basically
asm-time copy-propagation)

But rather than my mailing this around as is, might I ask who would be
willing to help me understand the piece I lack, namely a TN-ELIDABLE-P
predicate?

Regards and thanks,

Doug
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev_______________________________________________
Sbcl-devel mailing list
Sbcl-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

GC projects in the SBCL's Google summer of code?

Martin Cracauer — 2013-06-11T15:38:03

[CCing a few people who expressed interest]

How does it look for the GC projects in the GSoC? Namely 5.5. and 5.6
in the list?
http://www.sbcl.org/gsoc2013/ideas/

For my toy at work (ITA/Google's QPX search engine) we want to put
some more resources behind faster GC in large, badly behaving heaps.
If there's interest I would like to get in touch.

Martin

Over-enthusiastic type enforcement in DOLIST

Eric Marsden — 2013-06-09T09:27:17

Hi,


* (lisp-implementation-version)
"1.1.8.49-ded09c0-dirty"
* (let ((sum 0))
    (dolist (x '(0 1 2 3) sum)
      (declare (fixnum x))
      (incf sum x)))
; in: LET ((SUM 0))
;     (DOLIST (X '(0 1 2 3) SUM) (DECLARE (FIXNUM X)) (INCF SUM X))
; --> BLOCK 
; ==>
;   (LET ((X NIL))
;     (DECLARE (FIXNUM X))
;     X
;     SUM)
; 
; caught WARNING:
;   Constant NIL conflicts with its asserted type FIXNUM.
;   See also:
;     The SBCL Manual, Node "Handling of Types"
; 
; compilation unit finished
;   caught 1 WARNING condition

debugger invoked on a SIMPLE-TYPE-ERROR in thread
#<THREAD "main thread" RUNNING {1002ACB793}>:
  Value of NIL in
    (LET ((X NIL))
      (DECLARE (FIXNUM X))
      X
      SUM)

  is
    NIL,
  not a
    FIXNUM.


(From sacla-test)

Over-strict type checking for MAKE-HASH-TABLE

Eric Marsden — 2013-06-09T09:21:41

Hi,


* (lisp-implementation-version)
"1.1.8.49-ded09c0-dirty"
* (make-hash-table :rehash-size 1.0)
debugger invoked on a TYPE-ERROR in thread
#<THREAD "main thread" RUNNING {1002ACB793}>:
  The value 1.0
  is not of type
    (OR (INTEGER 1) (DOUBLE-FLOAT (1.0d0)) (SINGLE-FLOAT (1.0))).


(From sacla-test)

Over-rigid type enforcement in LOOP "counting it into"

Eric Marsden — 2013-06-09T09:06:27

Hi,

I'm telling you it's so.


* (lisp-implementation-version)
"1.1.8.49-ded09c0-dirty"
* (LOOP FOR A UPTO 10 SUMMING A INTO SUM WHEN (ODDP A) COUNTING IT INTO SUM)
WARNING: unequal datatypes specified in different LOOP value accumulations
into SUM: FIXNUM and NUMBER
current LOOP context: COUNTING IT INTO SUM.

debugger invoked on a SB-INT:SIMPLE-PROGRAM-ERROR in thread
#<THREAD "main thread" RUNNING {1002ACB793}>:
  The specified data type NUMBER is not a subtype of REAL.
current LOOP context: COUNTING IT INTO SUM.


(From sacla-tests)

Implicit initialization of WITH variables in LOOPclauses; spurious error

Eric Marsden — 2013-06-09T09:02:51

Hi,

CLtS 6.1.2.2 says that "If the optional type-spec argument is supplied
for the variable var, but there is no related expression to be
evaluated, var is initialized to an appropriate default value for its
type. For example, for the types t, number, and float, the default
values are nil, 0, and 0.0 respectively.".

It seems to me that in the example below (from the spec BTW, even if
examples are not normative), the compiler is raising a spurious error
concerning a LOOP-IGNORE-XX variable.


* (lisp-implementation-version)
"1.1.8.49-ded09c0-dirty"
* (loop with (a b c) of-type float return (format nil "~A ~A ~A" a b c))
; in: LOOP WITH
;     (LET ((A 0.0) (B 0.0) (C 0.0) (#:LOOP-IGNORE-609 NIL))
;       (DECLARE (TYPE FLOAT #:LOOP-IGNORE-609)
;                (IGNORE #:LOOP-IGNORE-609)
;                (TYPE FLOAT C)
;                (TYPE FLOAT B)
;                (TYPE FLOAT A))
;       (SB-LOOP::LOOP-BODY NIL NIL
;                           ((RETURN-FROM NIL (FORMAT NIL "~A ~A ~A" A B C))) NIL
;                           NIL))
; 
; caught WARNING:
;   Constant NIL conflicts with its asserted type FLOAT.


(From sacla-tests)

SF git repository out of sync

Eric Marsden — 2013-06-09T07:59:01

Hi,

A previous location of the SBCL git repository

   git://sbcl.git.sourceforge.net/gitroot/sbcl/sbcl.git

is stuck at commit 51bc001b7a98af096af782a672389e51004af068 from Lutz
Euler on June 6th. 

The repository at git://git.code.sf.net/p/sbcl/sbcl seems OK.

Git log access by web browser after Sourceforgemigration

Lutz Euler — 2013-06-08T11:23:43

Hi,

I used to browse SBCL's git log via

http://sbcl.git.sourceforge.net/git/gitweb.cgi?p=sbcl/sbcl.git;a=log

This seems not to get updated any more.
After some experimentation I found

http://sourceforge.net/p/sbcl/sbcl/ci/master/log/

now to provide something similar.

Regards,

Lutz

------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j

Suggestions for debugging memory leakage?

Eric Schulte — 2013-06-06T19:13:44

Hi,

I'm trying to debug memory leakage in a long running genetic programming
application.  I can instrument runs to see that my dynamic memory usage
grows monotonically.  However, I'm having trouble narrowing down *where*
the memory is going.  None of the obvious objects in the application are
increasing in size.

Ideally what I would like is a way to assign all of the bytes of the
dynamic space to named objects or variables, so that I can see where
these ever-growing bytes are living isolate the related code.  I've
tried using sb-vm:map-allocated-objects which crashed my lisp instance,
and also using sb-vm::print-allocated-objects (I had to search-replace
32 with 64 in the source of that function).  The later seems to get
close [1], but without fluency in the sbcl type language I'm having
trouble mapping the results to my own source code.

Does anyone have any suggestions, either related to this sort of memory
debugging in general, or specifically related to how to map dynamic
memory to lisp objects?

Many Thanks,

Footnotes: 
[1]  OPTIMIZE> (sb-vm::print-allocated-objects :dynamic :larger 500)

**** Page 0, address 100000000B:
(SIMPLE-VECTOR 256): #(#<FUNCTION SB-IMPL::HAIRY-REF-ERROR> #<FUNCTION SB-IMPL::H
(SIMPLE-VECTOR 256): #(#<FUNCTION SB-IMPL::HAIRY-REF-ERROR> #<FUNCTION SB-IMPL::H
(SIMPLE-VECTOR 256): #(#<FUNCTION SB-IMPL::HAIRY-REF-ERROR> #<FUNCTION SB-IMPL::H
(SIMPLE-VECTOR 256): #(#<FUNCTION SB-IMPL::HAIRY-REF-ERROR> #<FUNCTION SB-IMPL::H
SB-KERNEL:CODE-COMPONENT: #<code object SB-ALIEN-INTERNALS:ENTER-ALIEN-CALLBACK {10000
SB-KERNEL:CODE-COMPONENT: #<code object SB-KERNEL::CANONICAL-COMPLEX {100000393F}>
SB-KERNEL:CODE-COMPONENT: #<code object SB-KERNEL::CANONICAL-COMPLEX {10000051CF}>

**** Page 1, address 100000800F:
(SIMPLE-ARRAY (UNSIGNED-BYTE 8) (1973)): #(36 20 239 0 0 0 0 0 0 0 8 48 235 0 0 214 38 0 0 0 0 251 0 
(SIMPLE-ARRAY (UNSIGNED-BYTE 8) (617)): #(0 0 104 0 194 178 0 37 0 0 30 0 168 0 157 0 0 0 0 179 16 2
(SIMPLE-ARRAY (UNSIGNED-BYTE 8) (5741)): #(0 243 253 0 218 0 0 142 0 0 182 134 154 0 23 0 187 0 167 0
(SIMPLE-ARRAY (UNSIGNED-BYTE 8) (743)): #(40 69 0 0 0 0 125 56 0 0 69 150 244 29 60 223 0 0 16 10 17
(SIMPLE-ARRAY (UNSIGNED-BYTE 8) (2971)): #(0 0 92 0 0 107 134 0 0 0 52 0 0 29 212 0 0 71 0 0 0 121 22
(SIMPLE-ARRAY (UNSIGNED-BYTE 8) (2039)): #(0 0 145 66 0 0 0 176 46 0 0 200 0 0 51 0 98 208 10 45 0 18

**** Page 2, address 100001000F:
SB-KERNEL:CODE-COMPONENT: #<code object (LAMBDA (&OPTIONAL (SB-KERNEL::NUM) (SB-KERNEL
SB-KERNEL:CODE-COMPONENT: #<code object SB-KERNEL::MAYBE-TRUNCATE {100001179F}>
SB-KERNEL:CODE-COMPONENT: #<code object (LAMBDA (&OPTIONAL (SB-KERNEL::LO) (SB-KERNEL:
SB-KERNEL:CODE-COMPONENT: #<code object (LAMBDA (&OPTIONAL (SB-KERNEL::LO) (SB-KERNEL:

**** Page 3, address 100001800F:
SB-KERNEL:CODE-COMPONENT: #<code object (LAMBDA (&OPTIONAL (SB-KERNEL::LO) (SB-KERNEL:
SB-KERNEL:CODE-COMPONENT: #<code object SB-KERNEL:%EQL {100001924F}>
SB-KERNEL:CODE-COMPONENT: #<code object SB-KERNEL:%NEGATE {100001963F}>
SB-KERNEL:CODE-COMPONENT: #<code object SB-BIGNUM:MAKE-SMALL-BIGNUM {1000019ADF}>
SB-KERNEL:CODE-COMPONENT: #<code object SB-BIGNUM:MAKE-SMALL-BIGNUM {1000019F4F}>
SB-KERNEL:CODE-COMPONENT: #<code object SB-BIGNUM:MAKE-SMALL-BIGNUM {100001A3BF}>
SB-KERNEL:CODE-COMPONENT: #<code object SB-BIGNUM:MAKE-SMALL-BIGNUM {100001A82F}>
SB-KERNEL:CODE-COMPONENT: #<code object (LAMBDA (&OPTIONAL (MAX) (MIN) &REST #:G875) :
SB-KERNEL:CODE-COMPONENT: #<code object (SB-C::XEP (FLET SB-UNIX::INTERRUPTION :IN SB-
SB-KERNEL:CODE-COMPONENT: #<code object SB-VM::CONTEXT-PC-ADDR {100001B99F}>
SB-KERNEL:CODE-COMPONENT: #<code object SB-VM::CONTEXT-PC-ADDR {100001BFAF}>
SB-KERNEL:CODE-COMPONENT: #<code object SB-VM::CONTEXT-PC-ADDR {100001C34F}>
SB-KERNEL:CODE-COMPONENT: #<code object SB-VM:SIGFPE-HANDLER {100001C6EF}>
SB-KERNEL:CODE-COMPONENT: #<code object SB-IMPL::OUTPUT-UNSIGNED-BYTE-FULL-BUFFERED {1
SB-KERNEL:CODE-COMPONENT: #<code object (FLET #:STRING-DISPATCH-FUN1106 :IN SB-IMPL::F
SB-KERNEL:CODE-COMPONENT: #<code object (SB-C::ESCAPE-FUN #:EXIT-BLOCK-3139) {100001E3
(SIMPLE-VECTOR 128): #(NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NI

**** Page 4, address 100002000F:
SB-KERNEL:CODE-COMPONENT: #<code object SB-IMPL::ANSI-STREAM-P {100002060F}>
SB-KERNEL:CODE-COMPONENT: #<code object SB-IMPL::ANSI-STREAM-P {1000020BDF}>
SB-KERNEL:CODE-COMPONENT: #<code object (SB-C::ESCAPE-FUN #:EXIT-BLOCK-2056) {10000217
SB-KERNEL:CODE-COMPONENT: #<code object (SB-C::ESCAPE-FUN #:EXIT-BLOCK-2218) {1000021B
; No value

Building on Windows

Nick Levine — 2013-06-06T10:18:14

I've had this failure on 2 different machines: Win7 with up-to-date
Cygwin, and XP with Cygwin a couple of years old.

pthreads_win32.h says:

    #ifndef _SIGSET_T
    typedef int sigset_t;
    #endif

types.h says:

    #ifndef _SIGSET_T_
    #define_SIGSET_T_
    typedef int_sigset_t;

Is it supposed to be possible to build on Windows or is magick
required?

Thanks.

- nick


//entering make-target-1.sh
//building runtime system and symbol table file
make: Entering directory `/cygdrive/c/Users/nick/lisp/sbcl/src/runtime'
rm -f *.[do] sbcl.exe sbcl.nm sbcl.h core *.tmp 
make: Leaving directory `/cygdrive/c/Users/nick/lisp/sbcl/src/runtime'
make: Entering directory `/cygdrive/c/Users/nick/lisp/sbcl/src/runtime'
echo '#include "genesis/config.h"' >sbcl.h
echo '#include "genesis/constants.h"' >>sbcl.h
make: Leaving directory `/cygdrive/c/Users/nick/lisp/sbcl/src/runtime'
make: Entering directory `/cygdrive/c/Users/nick/lisp/sbcl/src/runtime'
gcc -g -Wall -O3  -fno-omit-frame-pointer -march=i686 -DWINVER=0x0501  -D__W32API_USE_DLLIMPORT__ -mno-cygwin -I. -DSBCL_PREFIX=\"'C:\Program Files (x86)/sbcl'\"  -c -o alloc.o alloc.c
In file included from runtime.h:19,
                 from alloc.c:21:
pthreads_win32.h:9: error: redefinition of typedef 'sigset_t'
/usr/i686-pc-mingw32/sys-root/mingw/include/sys/types.h:109: error: previous declaration of 'sigset_t' was here
pthreads_win32.h:338: warning: alignment of 'DEAD_MUTEX' is greater than maximum object file alignment.  Using 16
<builtin>: recipe for target `alloc.o' failed
make: *** [alloc.o] Error 1
make: Leaving directory `/cygdrive/c/Users/nick/lisp/sbcl/src/runtime'

------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j

Follow-up on find/position circularity detection

Douglas Katzman — 2013-06-05T21:15:51

Hi all,

To mention the easy bug first, and jumping right into the thick of it,
CIRCULAR-LIST-ERROR quite clearly binds *PRINT-CIRCLE* to T right before
invoking ERROR, but it gets either reset or rebound to NIL somewhere before
INVOKE-DEBUGGER.  Example:

* (sb-impl::CIRCULAR-LIST-ERROR '#1=(FOOL HI WHAT IS THIS . #1#))
debugger invoked on a SIMPLE-TYPE-ERROR:
  List is circular:
  (FOOL HI WHAT IS THIS FOOL HI WHAT IS THIS FOOL HI ...)

Ok, so that's irrelevant, but ... another reason that we hand-roll FIND is
that the builtin isn't able to eliminate the unused 'index' variable.  It's
easy to show that this has nothing to do with a multiple-value-bind of both
the element and its index and using only either the former or latter  from
%find-position-if.   In this minimal example:
(defun foofind (item list)
  (declare (optimize (speed 3) (safety 0)))
  (let ((ind 0))
    (declare (fixnum ind))
    (dolist (x list)
      (when (eq x item) (return x))
      (incf ind))))

The compiler is maintaining RDX inside the loop as shown in this
disassembly fragment:
; disassembly for FOOFIND
[...elided...]
;       B0: L0:   488B59F9         MOV RBX, [RCX-7]
;       B4:       488B4901         MOV RCX, [RCX+1]
;       B8:       4839F3           CMP RBX, RSI
;       BB:       7418             JEQ L3
;       BD:       4883C202         ADD RDX, 2

My understanding having read Paul's blog entry titled
"fixed-points-and-strike-mandates" was that SBCL *does* use the non-naive
approach of assuming that variables are dead until proven live, rather than
live until proven dead; and therefore that it should be able to prove that
'ind' is effectively dead because its value is used only to compute
"another" dead variable, namely, itself.

Is there an open bug with say 'wishlist' status for this already?  I didn't
see one.
Regards

-d
------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j_______________________________________________
Sbcl-devel mailing list
Sbcl-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

Building with SB-DYNCOUNT feature

Douglas Katzman — 2013-06-05T19:45:00

Attached patch corrects the dyncount code that hasn't worked for as far
back as I cared to examine.  In so far as "corrects" means "does the thing
that it probably always did", and not "the thing that you would think it
does based on the descriptions in comments".
(it counts basic block, not VOPs)

I can envision uses for this, as it injects far less overhead into the
assembly code than sb-cover and gives better data than just a T answer for
was it covered.
------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j_______________________________________________
Sbcl-devel mailing list
Sbcl-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

Breakage in sb-bsd-sockets on Windows

Elliott Slaughter — 2013-06-05T06:52:12

On head[1], sb-bsd-sockets appears to broken for Windows/x86. See build log
below. This is new since the release of 1.1.8.

https://elliottslaughter.com/files/build_sbcl-1.1.9-pretest-x86-windows.txt

[1]: f79e7df41edd15a68c763263a81e7c640005a60b

New? bug in LOGAND type derivation

Eric Marsden — 2013-06-03T07:56:55

Hi,

Many thanks for the fix to https://bugs.launchpad.net/sbcl/+bug/1026634.
While this is fresh in your memory, a possibly related bug (also from pfdietz
random-integer-testing). This is on AMD64.


* (lisp-implementation-version)
"1.1.8.10-f962bad-dirty"
* (defun foo (a b)
    (declare (optimize (speed 2) (safety 0)))
    (logand (the (eql 16779072918521075607) a)
            (the (integer 21371810342718833225 21371810343571293860) b)))
FOO
* (- (foo 16779072918521075607 21371810342718833263) 2923729245085762055)
18446744073709551616    ;; <-- expected 0

Bug in short sleeps

Eric Marsden — 2013-06-03T07:07:57

Hi,


* (lisp-implementation-version)
"1.1.8.10-f962bad-dirty"
* (sleep (/ 100000000000000))
debugger invoked on a TYPE-ERROR in thread
#<THREAD "main thread" RUNNING {1002AFB7C3}>:
  The value 1/100000 is not of type (SIGNED-BYTE 64).
Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT] Exit debugger, returning to top level.
(SB-UNIX:NANOSLEEP 0 1/100000)

SBCL 1.1.8 fails to build PVS 6.0

Jerry James — 2013-06-03T00:04:35

Greetings,

I maintain the PVS package for Fedora, which we build with SBCL.  The
SBCL maintainer just pushed version 1.1.8 into Fedora Rawhide, and now
PVS is failing to build.  The tail of the build log looks like this:

; compiling file
"/builddir/build/BUILD/pvs-6.0/ess/sys/ergolisp/rel/dlambda-lib.lisp"
(written 21 FEB 2013 03:19:16 PM):
; compiling (DEFPACKAGE :DLAMBDA-LIB ...)
; compiling (IN-PACKAGE :DLAMBDA-LIB)
; compiling (EEXPORT (QUOTE #))
; compiling (DECLARE-CONSTRUCTOR CONS ...)
; compiling (DECLARE-CONSTRUCTOR 1+ ...)
; compiling (DEFUN POSITIVEP ...)
; compiling (DECLARE-CONSTRUCTOR INTERN ...)
; compiling (DECLARE-CONSTRUCTOR REVERSE ...)
; compiling (DECLARE-CONSTRUCTOR ACONS ...)
; compiling (DEFUN ACONSP ...)
; compiling (DEFUN RE-MAPCAR ...)
debugger invoked on a SB-INT:SIMPLE-PROGRAM-ERROR in thread
#<THREAD "main thread" RUNNING {1002B33A33}>:
  invalid number of arguments: ((FIRST (FIRST #:G78)) (REST (REST #:G78)))
Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
  0: [RETRY   ] Retry EVAL of current toplevel form.
  1: [CONTINUE] Ignore error and continue loading file
"/builddir/build/BUILD/pvs-6.0/src/make-pvs-parser.lisp".
  2: [ABORT   ] Abort loading file
"/builddir/build/BUILD/pvs-6.0/src/make-pvs-parser.lisp".
  3:            Ignore runtime option --load "src/make-pvs-parser".
  4:            Skip rest of --eval and --load options.
  5:            Skip to toplevel READ/EVAL/PRINT loop.
  6: [EXIT    ] Exit SBCL (calling #'EXIT, killing the process).
(DLAMBDA::ARGS-BINDS ((FIRST (FIRST #1=#:G78)) (REST (REST #1#)))) [tl,external]
0] ;
; compilation unit aborted
;   caught 1 fatal ERROR condition
; compilation aborted after 0:00:00.033

I'm attaching a stripped-down version of the failure.  It builds
successfully with SBCL 1.1.7, but fails with 1.1.8.  Should this code
compile successfully, or is there something wrong with it?  Thanks,
--
Jerry James
http://www.jamezone.org/
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2_______________________________________________
Sbcl-devel mailing list
Sbcl-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

Bug in optimizer for NCONC

Eric Marsden — 2013-05-31T12:02:37

Hi,

There is something wrong with some compiler optimizations made to NCONC.


* (lisp-implementation-version)
"1.1.7.117-2378406-dirty"
* (lambda (a b)
    (declare (type atom a))
    (nconc a b))
#<FUNCTION (LAMBDA (A B)) {10035E13BB}>
* (funcall * nil (list 1))
debugger invoked on a SB-INT:SIMPLE-PROGRAM-ERROR in thread
#<THREAD "main thread" RUNNING {1002B23243}>:
  invalid number of arguments: (1)
restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT] Exit debugger, returning to top level.
((LAMBDA (A B)) (1) (1)) [tl,external]

failed AVER: (CSUBTYPEP (LVAR-TYPE INTEGER)(SPECIFIER-TYPE 'SIGNED-WORD))

Eric Marsden — 2013-05-30T17:11:18

Hi,


* (lisp-implementation-version)
"1.1.7.116-17dd0a1-dirty"
* (lambda (a b)
    (declare (type (member #\~ "kpsitvcpkrS6G" 485913 -1716676591 #\W -4117744) a)
             (type (rational * -84) b))
    (ash a b))

debugger invoked on a SB-INT:BUG in thread
#<THREAD "main thread" RUNNING {1002B23243}>:
    failed AVER: (CSUBTYPEP (LVAR-TYPE INTEGER) (SPECIFIER-TYPE 'SIGNED-WORD))
 restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT] Exit debugger, returning to top level.

0] backtrace
Backtrace for: #<SB-THREAD:THREAD "main thread" RUNNING {1002B23243}>
0: (SB-INT:BUG "~< at ><failed AVER: ~2I~_~A~:>" (SB-KERNEL:CSUBTYPEP (SB-C::LVAR-TYPE INTEGER) (SB-KERNEL:SPECIFIER-TYPE (QUOTE SB-VM:SIGNED-WORD))))
1: (SB-IMPL::%FAILED-AVER (SB-KERNEL:CSUBTYPEP (SB-C::LVAR-TYPE INTEGER) (SB-KERNEL:SPECIFIER-TYPE (QUOTE SB-VM:SIGNED-WORD))))
2: ((LAMBDA (SB-C::NODE) :IN "/usr/local/src/sbcl/src/cold/compile-cold-sbcl.lisp") #<SB-C::COMBINATION :FUN #<SB-C::REF  :LEAF #<SB-C::GLOBAL-VAR :%SOURCE-NAME SB-KERNEL:%ASH/RIGHT :TYPE #1=#<SB-KERNEL:FUN-TYPE (FUNCTION ((INTEGER -9223372036854775808 18446744073709551615) (UNSIGNED-BYTE 6)) (VALUES (INTEGER -9223372036854775808 18446744073709551615) &OPTIONAL))> :DEFINED-TYPE #1# :WHERE-FROM :DECLARED :KIND :GLOBAL-FUNCTION {10036A7C73}> {10036A8003}> :ARGS (#<CAST :%TYPE-CHECK T :VALUE #<SB-C::LVAR 1 {10036A8143}> :ASSERTED-TYPE #2=#<SB-KERNEL:NUMERIC-TYPE (INTEGER -9223372036854775808 18446744073709551615)> :TYPE-TO-CHECK #2# {10036AA083}> #<CAST :%TYPE-CHECK T :VALUE #<SB-C::LVAR 2 {10036A8393}> :ASSERTED-TYPE #3=#<SB-KERNEL:NUMERIC-TYPE (UNSIGNED-BYTE 6)> :TYPE-TO-CHECK #3# {10036AA1
 B3}>) {10036A8083}>)
3: (SB-C::IR1-TRANSFORM #<SB-C::COMBINATION :FUN #<SB-C::REF  :LEAF #<SB-C::GLOBAL-VAR :%SOURCE-NAME SB-KERNEL:%ASH/RIGHT :TYPE #1=#<SB-KERNEL:FUN-TYPE (FUNCTION ((INTEGER -9223372036854775808 18446744073709551615) (UNSIGNED-BYTE 6)) (VALUES (INTEGER -9223372036854775808 18446744073709551615) &OPTIONAL))> :DEFINED-TYPE #1# :WHERE-FROM :DECLARED :KIND :GLOBAL-FUNCTION {10036A7C73}> {10036A8003}> :ARGS (#<CAST :%TYPE-CHECK T :VALUE #<SB-C::LVAR 1 {10036A8143}> :ASSERTED-TYPE #2=#<SB-KERNEL:NUMERIC-TYPE (INTEGER -9223372036854775808 18446744073709551615)> :TYPE-TO-CHECK #2# {10036AA083}> #<CAST :%TYPE-CHECK T :VALUE #<SB-C::LVAR 2 {10036A8393}> :ASSERTED-TYPE #3=#<SB-KERNEL:NUMERIC-TYPE (UNSIGNED-BYTE 6)> :TYPE-TO-CHECK #3# {10036AA1B3}>) {10036A8083}> #<SB-C::TRANSFORM :TYPE #<SB-KERNEL:FUN-
 TYPE (FUNCTION * (VALUES (INTEGER -1 0) &REST T))> :NOTE "optimize" :IMPORTANT NIL>)
4: (SB-C::IR1-OPTIMIZE-COMBINATION #<SB-C::COMBINATION :FUN #<SB-C::REF  :LEAF #<SB-C::GLOBAL-VAR :%SOURCE-NAME SB-KERNEL:%ASH/RIGHT :TYPE #1=#<SB-KERNEL:FUN-TYPE (FUNCTION ((INTEGER -9223372036854775808 18446744073709551615) (UNSIGNED-BYTE 6)) (VALUES (INTEGER -9223372036854775808 18446744073709551615) &OPTIONAL))> :DEFINED-TYPE #1# :WHERE-FROM :DECLARED :KIND :GLOBAL-FUNCTION {10036A7C73}> {10036A8003}> :ARGS (#<CAST :%TYPE-CHECK T :VALUE #<SB-C::LVAR 1 {10036A8143}> :ASSERTED-TYPE #2=#<SB-KERNEL:NUMERIC-TYPE (INTEGER -9223372036854775808 18446744073709551615)> :TYPE-TO-CHECK #2# {10036AA083}> #<CAST :%TYPE-CHECK T :VALUE #<SB-C::LVAR 2 {10036A8393}> :ASSERTED-TYPE #3=#<SB-KERNEL:NUMERIC-TYPE (UNSIGNED-BYTE 6)> :TYPE-TO-CHECK #3# {10036AA1B3}>) {10036A8083}>)
5: (SB-C::IR1-OPTIMIZE-BLOCK #<SB-C::CBLOCK NIL :START c3 {10036A9293}>)
6: (SB-C::IR1-OPTIMIZE #<SB-C:COMPONENT :NAME (LAMBDA (A B)) :REANALYZE T {10036A4A03}> NIL)
7: (SB-C::IR1-OPTIMIZE-UNTIL-DONE #<SB-C:COMPONENT :NAME (LAMBDA (A B)) :REANALYZE T {10036A4A03}>)
8: (SB-C::IR1-PHASES #<SB-C:COMPONENT :NAME (LAMBDA (A B)) :REANALYZE T {10036A4A03}>)

my GSoC project

Alexandra Barchunova — 2013-05-30T07:21:12

Hello,

my student project "Modernising register allocation in SBCL" has been 
one of the two accepted  by google. Thanks to Paul Khuong for his 
crucial feedback!

Here is the preliminary plan/abstract:

This project aims to improve the compiler back end by enhancing the
  register allocation procedure.  To realize this goal, we propose to
  implement
+ a new heuristic optimization based on coloring the global
    interference graph,
+ live ranges and live range splitting,
+ spill code insertion.


The task of the register allocator is to assign an unconstrained
number of temporary names (TNs) in the intermediate representation
(IR) to a finite number of registers.  A naive approach yields too
many memory operations resulting in a reduced execution speed. The
currently implemented SBCL register allocator performs only graph
coloring, essentially treating spills by coloring with stack slots. In
order to improve the allocator, we propose to integrate a new
heuristic graph coloring method inspired by the concepts introduced by
Briggs et al. (1994) in the SBCL compiler.  According to Briggs'
results of the /optimistic coloring/, the proposed enhancements can be
expected to increase performance of produced code by up to 15%.

Greetings,
Alex
------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1_______________________________________________
Sbcl-devel mailing list
Sbcl-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel