- Workaround for ACL 5.0.1 TAGBODY bug.
- ALL-TIME SERIES BUG FIX: wrappers now inserted more precisely.
- Fixed GATHERING redundant wrapping.
- Prevented generation of some dead termination code.
Implementation:
- Abstracted use of wrapper component of frags.
- GENERATOR deftyped to CONS, not LIST, when necessary.
Current qualification list:
CMUCL 18b (cmucl-2.4.19-2) [SuSE Linux 6.3/Intel]
CMUCL 18c [Solaris]
LispWorks 4.1 [Windows NT 4.0 SP6]
clisp-99.01.08-21 with -a option [SuSE Linux 6.3/Intel]
ACL 5.0.1 [SuSE Linux 6.3/Intel]
http://series.sourceforge.net/
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
What kind of bug does ACL have with TAGBODY? Could you please give details?
Bruno
Look at the (defS mask .... form to see it patched.
Jon
Sent via Deja.com http://www.deja.com/
Before you buy.
> There is/was an error which shows up in compiled code only. In series
> mask(#z()) used to segfault. Lieven Marchand posted me a fix (thanks)
> and described it as :-
> " Basically the problem is a miscompilation of a
> second order forward referenced trampoline. As you can see in my
> patches I just change the forward reference to a backward one."
>
To expand a bit:
MASK creates something like the following (this is from memory, I
didn't keep a copy of my bug report):
#'(lambda () (tagbody (foo #'(lambda () (go f)) f)))
A closure of a GO in a closure over a TAGBODY with the tag not yet
encountered at the point of creating the closure.
This seems to trigger a bug in code generation. I had reduced the 200
line monstrosity defS generated to a ten liner but anything changed
after that made the problem disappear, even removing unused tags.
--
Lieven Marchand <m...@bewoner.dma.be>
If there are aliens, they play Go. -- Lasker
> This seems to trigger a bug in code generation. I had reduced the 200
> line monstrosity defS generated to a ten liner but anything changed
> after that made the problem disappear, even removing unused tags.
You macroexpanded defS MASK? Why not just the test expression raising the
problem?
> Lieven Marchand wrote:
>
> > This seems to trigger a bug in code generation. I had reduced the 200
> > line monstrosity defS generated to a ten liner but anything changed
> > after that made the problem disappear, even removing unused tags.
>
> You macroexpanded defS MASK? Why not just the test expression raising the
> problem?
>
The problem is in the closure that gets stored in the gen-fn field of
the series struct. It goes wrong for every use of MASK. Anyway, the
patch had to work at that level too, so I had to make sure my changes
to defS MASK had the correct effect.
I'm curious about all this work you're putting in. have you bothered to
alert bu...@franz.com with a test case so they could fix it and you could
do something more useful with your life?
#:Erik
I sent bu...@franz.com a rather large isolated macro expansion of the
defs mask problem, which seg'd when compiled. I dont have the spr to
hand right now. I didnt fully understand the code and didnt isolate the
problem, very clearly, but I could see it was something to do with
closures.
I got nothing but the mailer autoresponse from franz, but as trial-
edition user I wasnt expecting any more.
I think Lieven sent them a 10 liner which demonstrated the problem.
I send franz all the bugs I have found :-
like :element-type '(integer 0 1) on open didnt appear to work and
(make-sequence 'string (vector 1 2)) doesnt report an error
at least on my linux version.
Ooops, that should have been (make-list (vector 1 2)) doesnt report
an error. On the trial linux version you will run out of memory as it
tries to do something it shouldnt.
The spr's are spr21041 (element-type and streams) and
spr21710 (make-list not signalling error) if anyone wants
to follow it up.