Custom Query (1030 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (946 - 948 of 1030)

Ticket Resolution Summary Owner Reporter
#1262 fixed Invalid memory operation from %copy-ivector-to-ivector-predecrement-128bit R. Matthew Emerson Bill St. Clair
Description

I'm converting WOOD to run in CCL. It uses ccl::%copy-ivector-to-ivector to quickly copy (unsigned-byte 8) arrays. While stressing its btree code, I encountered an "Invalid memory operation" error in ccl::%copy-ivector-to-ivector-predecrement-128bit

The errors happens in 64-bit CCL 1.10 on both my iMac and my Windows laptop running Ubuntu 14.10.

Executing (copy-ivector-to-ivector-bug) from the attached file makes it happen. The GDB output at the bottom of the file is from my Windows laptop running Ubuntu 14.10.

#1264 wontfix hash tables, make-load-form bug? Jared Davis
Description

Hi,

I believe there may be a problem with the latest CCL trunk. The problem occurs when I try to load the :chunga library from a recent Quicklisp distribution.

The attached script can be used to recreate the problem.

Here is the error and a backtrace:

   [package chunga]..
   > Error: Special operator or global macro-function CCL::NHASH.MIN-SIZE can't be FUNCALLed or APPLYed
   > While executing: #<CCL::STANDARD-KERNEL-METHOD MAKE-LOAD-FORM (HASH-TABLE)>, in process listener(1).
   > Type :POP to abort, :R for a list of available restarts.
   > Type :? for other options.
   :b
   *(2B6B9E1701D8) : 0 (FUNCALL #'#<#<CCL::STANDARD-KERNEL-METHOD MAKE-LOAD-FORM (HASH-TABLE)>> #<HASH-TABLE :TEST EQUAL size 77/82 #x302000B7E21D> #<CCL::LEXICAL-ENVIRONMENT #x302000B236AD>) 189
    (2B6B9E1702C8) : 1 (FASL-SCAN-USER-FORM #<HASH-TABLE :TEST EQUAL size 77/82 #x302000B7E21D>) 197
    (2B6B9E1702F8) : 2 (FASL-SCAN-CLFUN #<Compiled-function CHUNGA:AS-KEYWORD (Non-Global)  #x302000B90F4F>) 197
    (2B6B9E170330) : 3 (FASL-SCAN ((23 81) (47 "home:ql-bug;bug_temp;inst;dists;quicklisp;software;chunga-1.1.6;known-words.lisp.newest") (70 #<# #:#-# #>) (4 #) (70 #<# #:#-# #>) ...)) 469
    (2B6B9E1703C8) : 4 (FASL-SCAN-FORMS-AND-DUMP-FILE ((23 81) (47 "home:ql-bug;bug_temp;inst;dists;quicklisp;software;chunga-1.1.6;known-words.lisp.newest") (70 #<# #:#-# #>) (4 #) (70 #<# #:#-# #>) ...) "/home/users/jared/.cache/common-lisp/ccl-1.11-f96-linux-x64/home/users/jared/ql-bug/bug_temp/inst/dists/quicklisp/software/chunga-1.1.6/known-words-TMP.lx64fsl" #<CCL::LEXICAL-ENVIRONMENT #x302000B236AD>) 237
    (2B6B9E170468) : 5 (%COMPILE-FILE "/home/users/jared/ql-bug/bug_temp/inst/dists/quicklisp/software/chunga-1.1.6/known-words.lisp" "/home/users/jared/.cache/common-lisp/ccl-1.11-f96-linux-x64/home/users/jared/ql-bug/bug_temp/inst/dists/quicklisp/software/chunga-1.1.6/known-words-TMP.lx64fsl" NIL NIL T T NIL T :DEFER NIL #<BACKEND LINUXX8664 #x3020001C645D> :UTF-8 NIL 0) 2965

It appears that this is provoked by the Chunga file known-words.lisp, found in:

   dists/quicklisp/software/chunga-1.1.6/known-words.lisp

I don't see that this file is particularly doing anything strange, so perhaps there is a CCL problem?

I notice that MAKE-LOAD-FORM has been changed recently:

svn blame:
     6         gb (defmethod make-load-form ((hash hash-table) &optional env)
     6         gb   (declare (ignore env))
 10731         gz   (let ((keytransF (nhash.keytransF hash))
     6         gb         (compareF (nhash.compareF hash))
     6         gb         (vector (nhash.vector hash))
  2584         gb         (private (if (nhash.owner hash) '*current-process*))
 16340         gz         (lock-free-p (hash-lock-free-p hash)))
 16340         gz 
     6         gb     (flet ((convert (f)
     6         gb              (if (or (fixnump f) (symbolp f))
     6         gb                `',f
     6         gb                `(symbol-function ',(function-name f)))))
     6         gb       (values
     6         gb        `(%cons-hash-table
 10731         gz          nil nil nil ,(nhash.grow-threshold hash) ,(nhash.rehash-ratio hash) ,(nhash.rehash-size hash)
 16340         gz         nil nil ,private ,lock-free-p ,(nhash.min-size hash))
 10731         gz        `(%initialize-hash-table ,hash ,(convert keytransF) ,(convert compareF) ',vector)))))

Thanks,

Jared

#1269 fixed Lambdas don't optimize Gary Byers Shannon Spires
Description

Optimization works on defun forms like the following:

(defun fptest1 (a b)
  (declare (optimize (speed 3) (safety 1) (debug 1))
           (single-float a b))
  (+ a b))

(disassemble 'fptest1)

We can see from the disassembly that it's using the addss* instruction and not calling .SPBUILTIN-PLUS, so we know the optimization is happening.

[*addss is X86. The ARM equivalent is fadds.]

But lambda forms like the following don't optimize in CCL:

(defun fptest8 ()
  (declare (optimize (speed 3) (safety 0) (debug 0)))
  (lambda (a b)
    (declare (optimize (speed 3) (safety 0) (debug 0))
             (single-float a b))
    (+ a b)))

(disassemble (fptest8))

Because the disassembly contains the telltale line (jmpq (@ .SPBUILTIN-PLUS)), we know that optimization isn't happening.

However, the following works:

(defparameter fptest14
        (lambda (a b)
          (declare (optimize (speed 3) (safety 1) (debug 1))
                   (single-float a b))
          (+ a b)))

(disassemble fptest14)

As you can see, the resulting disassembly has no call to .SPBUILTIN-PLUS but rather it calls (addss (% fp1) (% fp0)), indicating optimization is happening. So using a global variable rather than a defun seems to be a partial workaround for anonymous functions, but not closures.

Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.