Custom Query (1030 matches)
Results (946 - 948 of 1030)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #1262 | fixed | Invalid memory operation from %copy-ivector-to-ivector-predecrement-128bit | ||
| 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? | ||
| 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 | ||
| 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. |
|||
