Now -- could that be loop unrolling that exceeded the max size that PROGN
takes in GCL?
J.
On November 9, 2018 5:23:05 PM GMT-02:00, Jeronimo Pellegrini
<[email protected]> wrote:
>Hello,
>
>So -- I had used GCL in the past with Spartns
>(https://gitlab.com/jpellegrini/spartns)
>and it worked fine. However, currently this is what happens:
>
>- the released version (Debian package, 2.6.12-80) fails
> several Spartns unit tests. This is finem because:
>
>- the git checkout does pass all tests! However, when running
> the benchmarks, it exits abnormally:
>
>$ GCL_ANSI=1 gcl
>GCL (GNU Common Lisp) 2.7.0 ANSI Nov 6 2018 23:26:25
>Source License: LGPL(gcl,gmp,pargcl), GPL(unexec,bfd,xgcl)
>Binary License: GPL due to GPL'ed components: (XGCL READLINE UNEXEC)
>Modifications of this banner must retain notice of a compatible license
>Dedicated to the memory of W. Schelter
>
>Use (help) to get some basic information on how to use GCL.
>Temporary directory for compiler files set to /tmp/user/1000/
>
>>(si::use-fast-links nil)
>
>NIL
>
>>(load "do-benchmarks.lisp")
>...
>... ;; lots of normal output here, from other functions being compiled
>...
>;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0,
>Speed=3, (Debug quality ignored)
>;; Finished compiling /tmp/user/1000/gazonk_12854_0.o.
>;; Loading #P"/tmp/user/1000/gazonk_12854_0.o"
>
>Error:
>Signalled by PROGN.
>Condition in PROGN [or a callee]: INTERNAL-SIMPLE-ERROR: The assertion
>v && (unsigned long)(v+sz)<MAX_CODE_ADDRESS
> on line 1035 of alloc.c in function alloc_code_space
> failed: Success
>
>Broken at SYSTEM::BREAK-LEVEL. Type :H for Help.
> 1 Return to top level.
>SPARTNS>> :bt
>
>#0 INVOKE-DEBUGGER {loc0=#<conditions::internal-simple-error.0>}
>[ihs=21]
>#1 LOAD-FASL {loc0=#P"/tmp/user/1000/gazonk_12854_0.o",loc1=nil}
>[ihs=18]
>#2 LOAD-PATHNAME
>{loc0=#P"/tmp/user/1000/gazonk_12854_0.o",loc1=nil,loc2=:error,loc3=nil,loc4=nil...}
>[ihs=17]
>#3 LOAD {loc0=#P"/tmp/user/1000/gazonk_12854_0.o"} [ihs=16]
>#4 COMPILE {loc0=run-cvector-get,loc1=(nil),loc2=nil} [ihs=15]
>#5 LOAD-STREAM {} [ihs=11]
>#6 LOAD-PATHNAME
>{loc0=#P"benchmark.lisp",loc1=nil,loc2=:error,loc3=nil,loc4=nil,loc5=#<input
>str...} [ihs=10]
>#7 LOAD {loc0="benchmark.lisp"} [ihs=9]
>#8 LOAD-STREAM {} [ihs=7]
>#9 LOAD-PATHNAME
>{loc0=#P"do-benchmarks.lisp",loc1=nil,loc2=:error,loc3=nil,loc4=nil,loc5=#<input...}
>[ihs=6]
>#10 LOAD {loc0="do-benchmarks.lisp"} [ihs=5]
>
>The benchmarks were written in a very lazy state of mind, so I have
>a big macro that generates lots of functions. But I wasn't expecting
>this,
>since the generated functions are actually simple (nested loops for
>accessing
>vectors and hashtables, mostly)...
>
>What does the error mean?
>It's funny that the error happens not during the execution of the
>benchmark,
>but when the function (which is quite simple actually) is being
>compiled!
>
>That something called "MAX_CODE_ADDRESS" has been exceeded makes me
>worried! :-)
>
>What could I possibly be doing to trigger that?
>
>(Anyway -- ECL, SBCL, Clisp, ccl seem to compile and run the benchmarks
>with no
> problem)
>
>
>The easy way to reproduce:
>
>$ git clone https://gitlab.com/jpellegrini/spartns.git
>$ cd spartns
>$ GCL_ANSI=1 gcl
>> (si::use-fast-links nil)
>
>> (load "do-benchmarks.lisp")
>
>
>Thanks,
>J.
>
>
>_______________________________________________
>Gcl-devel mailing list
>[email protected]
>https://lists.gnu.org/mailman/listinfo/gcl-devel
--
Sent from my Android device with K-9 Mail. Please excuse my brevity._______________________________________________
Gcl-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gcl-devel
