cmucl issueshttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues2017-03-27T06:32:34Zhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/27Regression: ASDF test failures2017-03-27T06:32:34ZElias PippingRegression: ASDF test failuresI have not had the time to look into what goes wrong here but I've just found that two ASDF tests are failing with today's master branch of cmucl (revision 5beb6431855908e9010c36bc9aeaa57b0daebcf3) that pass with cmucl-21a.
Please exp...I have not had the time to look into what goes wrong here but I've just found that two ASDF tests are failing with today's master branch of cmucl (revision 5beb6431855908e9010c36bc9aeaa57b0daebcf3) that pass with cmucl-21a.
Please expect more information shortly, I'm just hoping for this to block any release that might be in the making.
The failing tests are `asdf-pathname-test.script` and `test-logical-pathname.script`. They can be run from within an ASDF checkout e.g. via
```shell
make; make ext; CMUCL=cmucl-21a ./test/run-tests.sh cmucl asdf-pathname-test.script test-logical-pathname.script
```
where `cmucl-21a` is the name of the cmucl executable in my case.
**Update**: In both cases, the test fails because of a *Control stack overflow*.snapshot-2016-09Raymond ToyRaymond Toyhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/28Recursive function definition during cross-compile2017-03-27T06:32:34ZRaymond ToyRecursive function definition during cross-compileWhen cross-compiling from x86->x86, sparc->sparc, and x86->sparc, there's a message about a recursive function definition while compile `%single-float` and `%double-float`. On x86, this doesn't seem to cause a problem, but on sparc (spa...When cross-compiling from x86->x86, sparc->sparc, and x86->sparc, there's a message about a recursive function definition while compile `%single-float` and `%double-float`. On x86, this doesn't seem to cause a problem, but on sparc (sparc->sparc or x86->sparc cross-compile), this actually prevents loading the kernel.core; it's stuck in an infinite loop.snapshot-2016-09Raymond ToyRaymond Toyhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/101Maxima gets overflow with latest snapshot 2021-012021-02-06T20:01:26ZRaymond ToyMaxima gets overflow with latest snapshot 2021-01Building maxima with the latest snapshot-2021-01 works fine, but
running the testsuite produces 3 errors that didn't happen with
snapshot 2020-04. The overflow comes from `airy_ai(2.0)`, which calls
`slatec::daie`. The error is
```
Ari...Building maxima with the latest snapshot-2021-01 works fine, but
running the testsuite produces 3 errors that didn't happen with
snapshot 2020-04. The overflow comes from `airy_ai(2.0)`, which calls
`slatec::daie`. The error is
```
Arithmetic error FLOATING-POINT-OVERFLOW signalled.
Operation was *, operands (1.7976931348623157e308 NIL).
[Condition of type FLOATING-POINT-OVERFLOW]
Restarts:
0: [MACSYMA-QUIT] Maxima top-level
```
The backtrace points to
```
(EXPT (F2CL-LIB:D1MACH 2) 0.6666)
```
This can be reproduced by:
```
(require :f2cl)
(make-package "SLATEC")
(setf *read-default-float-format* 'double-float)
(dolist (f '("initds" "dcsevl" "d9aimp" "daie"))
(compile-file f :load t))
(slatec::daie 2d0)
```
The listed files come from the `src/numerical/slatec` directory from
maxima's sources.
A disassemble of`slatec::daie` appears to be essentially the same
between snapshot 2020-04 and 2021-01. The differences are the
address of the static vars for allocation, and the addresses of the
code constants. 2021-01 removed some static symbols so the address
changes are expected.
I have no idea what the problem could be; there weren't that many
changes between 2020-04 and 2021-01.Raymond ToyRaymond Toy