cmucl issueshttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues2021-02-06T20:01:26Zhttps://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 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/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/288Re-enable deftransform for random integers2024-03-24T15:09:54ZRaymond ToyRe-enable deftransform for random integers## Describe the bug
We have a [`deftransform` for word-sized random
integers](src/compiler/float-tran.lisp#L279). This was used for the
MT19937 generator. I think we forgot about this when we implemented
the xoroshiro generator.
We ca...## Describe the bug
We have a [`deftransform` for word-sized random
integers](src/compiler/float-tran.lisp#L279). This was used for the
MT19937 generator. I think we forgot about this when we implemented
the xoroshiro generator.
We can see this if we place this code in a file and compile it to
produce a trace file:
```
(defun zot ()
(random 100000))
```
## To Reproduce
Steps to reproduce the behavior:
1. Compile the above code with `:trace-file t`
2. Look at the trace file. You can see a call to `truncate`.
## Expected behavior
We should be doing a multiply instead of a truncate. Note also that
this is a bug in that `random` uses a
[multiplication](src/code/rand-xoroshiro.lisp#L493). We need to be
consistent between the two code paths. I guess in practice, this is
not so easy to see, but we could probably create a simple test for
this.
## Desktop (please complete the following information):
- OS: All
- Version: Any version after xoroshiro was implemented.SnapshotRaymond ToyRaymond Toyhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/285Wrong vop used for integer-length of (unsigned-byte 31) number?2024-03-22T17:18:47ZRaymond ToyWrong vop used for integer-length of (unsigned-byte 31) number?## Describe the bug
For some reason we use the `signed-byte-32-int-len` vop when the arg
is an `(unsigned-byte 31)`. Here is a test function:
```
(defun baz (n)
(declare (type (unsigned-byte 32) n)
(optimize (speed 3)))
...## Describe the bug
For some reason we use the `signed-byte-32-int-len` vop when the arg
is an `(unsigned-byte 31)`. Here is a test function:
```
(defun baz (n)
(declare (type (unsigned-byte 32) n)
(optimize (speed 3)))
(let ((x (ash n -1)))
(values x
(integer-length x)
(integer-length n))))
```
## To Reproduce
Steps to reproduce the behavior:
1. Save the test function in a file and compile it with the
`:trace-file t` option.
2. Examine the trace file.
3. We can see in one case we use the `signed-byte-32-int-len` VOP
## Expected behavior
I was expecting to see the `unsigned-byte-32-int-len` VOP for both
cases.
## Screenshots
If applicable, add screenshots to help explain your problem.
## Desktop (please complete the following information):
- OS: x86
- Version: snapshot-2023-04 and probably earlier
## Additional context
The relevant part of the trace file is:
```
IR2 block start c1
L4:
0: SAP-MOVE t19[S1]>t23[EAX] => t24[S1]<t25[EAX]
1: NOTE-ENVIRONMENT-START {#<NEW-ASSEM:LABEL 5>}
2: FAST-ASH-RIGHT/UNSIGNED=>UNSIGNED N!14[EDX] '1!26 => t27[EAX]
3: WORD-MOVE t27[EAX] => t28[ECX]
4: SIGNED-BYTE-32-LEN t28[ECX] => t29[EDI]
5: UNSIGNED-BYTE-32-LEN N!14[EDX] => t30[ESI]
```
Maybe the solution is to get rid of `signed-byte-32-int-len` VOP and
have the compiler generate a `(lognot x)` when `x` is a negative
number? But I see that sparc and ppc already have both signed and
unsigned versions, so this approach would work for those other archs
as well.
I don't know why the compiler is choosing the signed version of the
vop when the arg type is an `(unsigned-byte 31)`. (You can see this
by doing `(describe 'baz)` and looking at the return types.)Raymond ToyRaymond Toyhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/283integer-length for unsigned-byte 32 arg is slow2024-03-22T16:48:47ZRaymond Toyinteger-length for unsigned-byte 32 arg is slow## Describe the bug
Consider these functions:
```
(defun zot-u (n)
(declare (type (unsigned-byte 32) n)
(optimize (speed 3)))
(integer-length n))
(defun zot-s (n)
(declare (type (signed-byte 32) n)
(optimi...## Describe the bug
Consider these functions:
```
(defun zot-u (n)
(declare (type (unsigned-byte 32) n)
(optimize (speed 3)))
(integer-length n))
(defun zot-s (n)
(declare (type (signed-byte 32) n)
(optimize (speed 3)))
(integer-length n))
```
## To Reproduce
Steps to reproduce the behavior:
1. Compile `zot-u` and `zot-s`
2. Disassemble `zot-u` and `zot-s`
3. See that the disassembly of `zot-s` uses the BSR instruction to
compute the result of `integer-length`
4. But note that `zot-u` doesn't and calls the `integer-length`
function.
## Expected behavior
`zot-u` should be able to use the `BSR` instruction to compute the
`integer-length` of an `(unsigned-byte 32)` number.
## Desktop (please complete the following information):
- OS: Any x86
- Version: 21d and probably everything earlier
## Additional context
We need to define a new vop to handle `integer-length` when the arg is
an `(unsigned-byte 32)` value.SnapshotRaymond ToyRaymond Toyhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/282Random floats probably lose a bit of randomness2024-03-23T23:06:29ZRaymond ToyRandom floats probably lose a bit of randomness## Describe the bug
The code to generate random single-float and double-float values loses
a bit of randomness because they smash the bits of an integer into a
float and subtract that float from 1.
As mentioned in the section "Generati...## Describe the bug
The code to generate random single-float and double-float values loses
a bit of randomness because they smash the bits of an integer into a
float and subtract that float from 1.
As mentioned in the section "Generating uniform doubles in the unit
interval" from https://prng.di.unimi.it/, with this method
> *you will be generating half the values you could actually
> generate*.... All doubles generated will have the lowest significand
> bit set to zero
They recommend right shifting the 64-bit random integer by 11 and
multiplying by 2-53 (for doubles).
Since we've changed the generator in #276, perhaps this is also a good
time to change how floats are generated.
## Desktop (please complete the following information):
- OS: All
- Version: 21d and laterhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/280Ansi-test etypecase.15 fails on Darwin with xoroshiro128** RNG2024-03-13T02:32:36ZRaymond ToyAnsi-test etypecase.15 fails on Darwin with xoroshiro128** RNG## Describe the bug
When running the ansi-tests using the branch for !192, the ansi-tests
pass except for one new failure in `etypecase.15`.
## To Reproduce
Steps to reproduce the behavior:
1. Build the code for !192
2. `./bin/run-ansi...## Describe the bug
When running the ansi-tests using the branch for !192, the ansi-tests
pass except for one new failure in `etypecase.15`.
## To Reproduce
Steps to reproduce the behavior:
1. Build the code for !192
2. `./bin/run-ansi-tests.sh -l <lisp>`
3. Look at "../ansi-tests/test.out"
4. See error
## Expected behavior
This used to pass, but presumably this is failing now because the RNG
has changed so that different random tests are being run. For
whatever reason, we don't see this on Linux.
## Desktop (please complete the following information):
- OS: Darwin
- Version: !192
## Additional context
Here's the relevant section of the log:
```
Test ETYPECASE.15 failed
Form: (LET* ((U (COERCE *UNIVERSE* 'VECTOR))
(LEN1 (LENGTH U))
(TYPES (COERCE *CL-ALL-TYPE-SYMBOLS* 'VECTOR))
(LEN2 (LENGTH TYPES)))
(LOOP FOR N = (RANDOM 10)
FOR MY-TYPES = (LOOP REPEAT N COLLECT (ELT TYPES (RANDOM LEN2)))
FOR VAL = (ELT U (RANDOM LEN1))
FOR I = (POSITION VAL MY-TYPES :TEST #'TYPEP)
FOR FORM =
`#'(LAMBDA (X)
(HANDLER-CASE
(ETYPECASE X
(LISP::BACKQ-COMMA-AT
(LOOP FOR I FROM 0
FOR TYPE IN MY-TYPES
COLLECT `(,TYPE ,I))))
(TYPE-ERROR (C) (ASSERT (EQL X (TYPE-ERROR-DATUM C)))
(LET* ((EXPECTED (TYPE-ERROR-EXPECTED-TYPE C)))
(FORMAT T
,"expected ~S my-types ~S~%"
EXPECTED
'(OR ,@MY-TYPES))
(LET ((EQUIV
(CHECK-EQUIVALENCE EXPECTED
'(OR ,@MY-TYPES))))
(ASSERT (NULL EQUIV) NIL "EQUIV = ~A" EQUIV)))
NIL)))
FOR J = (FUNCALL (EVAL FORM) VAL)
REPEAT 200
UNLESS (EQL I J) COLLECT (LIST N MY-TYPES VAL I FORM J)))
Expected value:
NIL
Actual value:
#<SIMPLE-ERROR {4AD61D3D}> [
Error in function LISP::ASSERT-ERROR:
EQUIV = (((SUBTYPEP
'(NOT
(OR PATHNAME
BOOLEAN
STANDARD-CHAR
STANDARD-OBJECT
CHARACTER
FILE-ERROR))
'(NOT
(OR FILE-ERROR
CHARACTER
STANDARD-OBJECT
STANDARD-CHAR
BOOLEAN
PATHNAME)))
==> NIL T))]
```
I think this is a new legitimate failure; cmucl doesn't handle the
`subtypep` correctly. We do know that cmucl is not so good at
handling subtypes using `not`, although it's been a long time since I
looked at such things.https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/279Extra instruction in generated code for (ldb (byte 3 29) x)2024-03-08T21:39:19ZRaymond ToyExtra instruction in generated code for (ldb (byte 3 29) x)## Describe the bug
There appears to be an extra instruction in computing `(ldb (byte 3
29) x)`, which gets the top 3 bits of a 32-bit number.
The test function is
```
(defun hi3 (x)
(declare (type (unsigned-byte 32) x)
(optimize...## Describe the bug
There appears to be an extra instruction in computing `(ldb (byte 3
29) x)`, which gets the top 3 bits of a 32-bit number.
The test function is
```
(defun hi3 (x)
(declare (type (unsigned-byte 32) x)
(optimize (speed 3) (safety 0)))
(ldb (byte 3 (- 32 3)) x))
```
## To Reproduce
Steps to reproduce the behavior:
1. Put the test function above in a file, say "hi3.lisp"
2. `(compile-file "hi3" :load t :trace-file t)
3. `(disassemble 'hi3)` or look at the trace file.
## Expected behavior
The disassembly shows, in part:
```
a6: L1: shr edx, #x1d ; No-arg-parsing entry point
; [:non-local-entry]
a9: and edx, #x7
ac: shl edx, #x2
```
So we correctly did a logical right shift of 29 bits to move the high
3 bits to the lowest 3 bits of the register. But then we `and` that
with 7. There's no need to do this `and` operation since we're
shifting out the top 3 bits of the 32-bit integer.
Probably a deficiency in `ldb` not recognizing that we've shifted in
zeroes. If, say, we weren't getting the top 3 bits, then the `and`
operation would be needed to clear out the bits we don't want.
Definitely needed for something like `(ldb (byte 3 20 x)`.
This is pretty minor micro optimization that we could do.
## Desktop (please complete the following information):
- OS: All x86
- Version: 21ehttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/277float-ratio-float returns 0 for numbers close to least-positive-float2024-03-23T19:43:49ZRaymond Toyfloat-ratio-float returns 0 for numbers close to least-positive-float## Describe the bug
`kernel::float-ratio-float` returns zero (when underflows are
disabled) for numbers that are just less least-positive float. I
think the it should return the least-positive float value instead
because it's closer tha...## Describe the bug
`kernel::float-ratio-float` returns zero (when underflows are
disabled) for numbers that are just less least-positive float. I
think the it should return the least-positive float value instead
because it's closer than 0.
## To Reproduce
Steps to reproduce the behavior:
1. Evaluate `(kernel::float-ratio-float (/ 4 (expt 10 324)) 'double-float)`
2. This returns 0d0
## Expected behavior
I was kind of expecting $4\times 10^{-324}$ to be returned because
that is closer to `least-positive-double-float`
(4.9406564584124654d-324) than it is to 0.
We have the same issue with `single-float`'s and `double-double-float`'s.
## Desktop (please complete the following information):
- OS: All
- Version: snapshot-2023-08
## Additional context
Add any other context about the problem here.SnapshotRaymond ToyRaymond Toyhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/2751d-400 signals error instead of returning 0d02024-03-23T21:42:50ZRaymond Toy1d-400 signals error instead of returning 0d0## Describe the bug
Cmucl signals an error when reading very small floats
## To Reproduce
Steps to reproduce the behavior:
1. Enter 1d-400 at the repl
2. See the error that the number is not representable as a `double-float`
## Expecte...## Describe the bug
Cmucl signals an error when reading very small floats
## To Reproduce
Steps to reproduce the behavior:
1. Enter 1d-400 at the repl
2. See the error that the number is not representable as a `double-float`
## Expected behavior
I think we should return 0d0 in this case. And if underflows are
enabled, we should signal an underflow.
## Desktop (please complete the following information):
- OS: All
- Version: snapshot-2023-08Raymond ToyRaymond Toyhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/2741d99999999999 hangs2024-03-23T19:43:49ZRaymond Toy1d99999999999 hangs## Describe the bug
Computing `1d9999999999999`, after selecting the `continue` restart,
appears to hang cmucl.
## To Reproduce
Steps to reproduce the behavior:
1. Enter `1d9999999999999` (the exact exponent doesn't matter; just
need...## Describe the bug
Computing `1d9999999999999`, after selecting the `continue` restart,
appears to hang cmucl.
## To Reproduce
Steps to reproduce the behavior:
1. Enter `1d9999999999999` (the exact exponent doesn't matter; just
needs to be large).
2. Select the `continue` restart
3. Cmucl now seems to hang.
4. Press `C-c` to get to the debugger. A backtrace shows that we're
doing Karatsuba multiplications
## Expected behavior
Not really sure, but this number is so large it definitely can't fit
in a `double-float`. Not only that, it's so large that the integer
`10^9999999999999` that we're trying to compute won't fit in memory
either.
## Desktop (please complete the following information):
- OS: All
- Version: snapshot-2023-08
## Additional context
This was found from the [ecl bug
675](https://gitlab.com/embeddable-common-lisp/ecl/-/issues/675),
where ecl exhausts the heap. Presumably cmucl would also run out of
heap if I let it run long enough.SnapshotRaymond ToyRaymond Toyhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/267walker:macroexpand-all doesn't macroexpand symbol-macros passed in environment2023-11-09T00:34:29ZAlexander Fedorovwalker:macroexpand-all doesn't macroexpand symbol-macros passed in environment## Description
`walker:macroexpand-all` doesn't expand symbol-macros when its definition is contained in the lexical environment passed (both global symbol-macros and local symbol-macros).
## "Mega" test
Here is a test for 6 possible ...## Description
`walker:macroexpand-all` doesn't expand symbol-macros when its definition is contained in the lexical environment passed (both global symbol-macros and local symbol-macros).
## "Mega" test
Here is a test for 6 possible cases where macro expansion should happen:
```common-lisp
;; utility macro
(defmacro at-compile-time ((&optional env) &body body)
(let ((capture (gensym)))
`(macrolet ((,capture (,@(when env `(&environment ,env)))
,@body))
(,capture))))
(defmacro NO-1 () ''YES-1)
(define-symbol-macro NO-4 'YES-4)
(macrolet ((NO-3 () ''YES-3))
(symbol-macrolet ((NO-6 'YES-6))
(at-compile-time (env)
`',(walker:macroexpand-all
'(macrolet ((NO-2 () ''YES-2))
(symbol-macrolet ((NO-5 'YES-5))
(values (NO-1) (NO-2) (NO-3) NO-4 NO-5 NO-6)))
env))))
```
The produced expansion:
```common-lisp
(MACROLET ((NO-2 ()
''YES-2))
(SYMBOL-MACROLET ((NO-5 'YES-5))
(VALUES 'YES-1 'YES-2 'YES-3 NO-4 'YES-5 NO-6)))
```
Expected expansion:
```common-lisp
(MACROLET ((NO-2 ()
''YES-2))
(SYMBOL-MACROLET ((NO-5 'YES-5))
(VALUES 'YES-1 'YES-2 'YES-3 'YES-4 'YES-5 'YES-6)))
```
## "Mini" tests
Smaller tests for those two cases where macroexpansion doesn't happen:
```common-lisp
(define-symbol-macro macroexpand-all-test-1 'expanded)
(walker:macroexpand-all 'macroexpand-all-test-1)
; => MACROEXPAND-ALL-TEST-1
```
```common-lisp
(symbol-macrolet ((macroexpand-all-test-2 'expanded))
(macrolet ((thunk (&environment env)
`',(walker:macroexpand-all
'macroexpand-all-test-2
env)))
(thunk)))
; => MACROEXPAND-ALL-TEST-2
```
## Additional information
Comparison of `macroexpand-all` provided by different implementations (using a portability layer, `trivial-macroexpand-all`): https://plaster.tymoon.eu/view/4009#4009
SBCL, CCL and ABCL expand (symbol-)macros in all 6 cases.
Allegro CL, LispWorks and CLISP expand macros in 4 cases; not accepting an additional environment argument.
## Desktop (please complete the following information):
- OS: Linux
- Version: 21ehttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/264Conformance issue: COMPILER-MACRO-FUNCTION2023-10-24T21:30:11ZAlexander FedorovConformance issue: COMPILER-MACRO-FUNCTION## Describe the bug
While it is documented that "if the name is ... declared NOTINLINE, NIL is returned" from the `compiler-macro-function`, it would seem that it is violates the standard.
The hyperspec page for notinline declaration sa...## Describe the bug
While it is documented that "if the name is ... declared NOTINLINE, NIL is returned" from the `compiler-macro-function`, it would seem that it is violates the standard.
The hyperspec page for notinline declaration says that
> a notinline declaration prevents that compiler macro from being used
But doesn't says that it shadows the compiler macro. So the *function name* that was declared notinline still should be naming both a *function* and a *compiler macro*; and thus `compiler-macro-function` should not return nil, as per entry for compiler-macro-function:
> A value of nil denotes the absence of a compiler macro function named name.
## To Reproduce
```lisp
(defun foo ())
; => FOO
(define-compiler-macro foo ())
; => FOO
(declaim (notinline foo))
; => NIL
(compiler-macro-function 'foo)
; => NIL
```
## Expected behavior
The call to `compiler-macro-function` should have returned a function.
## Desktop (please complete the following information):
- OS: Linux
- Version: 21e
## Additional context
This change was introduced in commit https://gitlab.common-lisp.net/cmucl/cmucl/-/commit/e69992175ccdcd7f895cff99752b809057c615df while fixing issue https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/3
This causes an issue in alexandria's tests: https://gitlab.common-lisp.net/alexandria/alexandria/-/issues/37
SBCL, CCL, Allegro CL, ECL, CLASP, ABCL, CLISP and LispWorks all return a function in this case.
CLHS links:
http://www.lispworks.com/documentation/HyperSpec/Body/f_cmp_ma.htm#compiler-macro-function
http://www.lispworks.com/documentation/HyperSpec/Body/d_inline.htm#notinlinehttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/263:ALLOW-OTHER-KEYS in compiled code2023-10-17T13:34:31ZAlexander Fedorov:ALLOW-OTHER-KEYS in compiled code## Describe the bug
`:allow-other-keys` is not handled correctly in compiled code when a key argument with the name `allow-other-keys` is present.
## To Reproduce
```lisp
;; This should return 10, but signals an error:
(funcall (compile...## Describe the bug
`:allow-other-keys` is not handled correctly in compiled code when a key argument with the name `allow-other-keys` is present.
## To Reproduce
```lisp
;; This should return 10, but signals an error:
(funcall (compile nil '(lambda (&key allow-other-keys) allow-other-keys)) :allow-other-keys 10 :foo 20)
; Unknown keyword: :FOO
; [Condition of type KERNEL:SIMPLE-PROGRAM-ERROR]
```
## Desktop (please complete the following information):
- OS: Linux
- Version: 21ehttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/259system::*software-version* undefined when compiling on linux2023-11-29T22:42:02ZRaymond Toysystem::*software-version* undefined when compiling on linux## Describe the bug
`system::*software-version*` is undefined when compiling on Linux.
## To Reproduce
Steps to reproduce the behavior:
1. Compile cmucl on linux
2. Look at compile-lisp.log at the end for the warning about the
define...## Describe the bug
`system::*software-version*` is undefined when compiling on Linux.
## To Reproduce
Steps to reproduce the behavior:
1. Compile cmucl on linux
2. Look at compile-lisp.log at the end for the warning about the
defined variable.
## Expected behavior
There should be no warning.
## Desktop (please complete the following information):
- OS: Linux
- Version: 21e
## Additional context
linux-os.lisp accesses `*software-version*` in `os-init`. The package
is "SYSTEM", so `os-init` is setting `system::*software-version*`.
However, we should probably be setting `lisp::*software-version*`
instead.
But also note that in many foo-os.lisp files, there's a `defvar` for
`*software-version*`. We probably didn't update those files when
fixing #120 because we had no way to test them. Notably bsd-os.lisp,
linux-os.lisp and sunos-os.lisp don't have a `defvar`.SnapshotRaymond ToyRaymond Toyhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/258linux-os.lisp calls unix:unix-getpagesize2023-09-05T00:05:00ZRaymond Toylinux-os.lisp calls unix:unix-getpagesize## Describe the bug
There's a compiler warning that in linux-os.lisp, `get-page-size` is calling the unknown function `unix:unix-getpagesize`
## To Reproduce
Steps to reproduce the behavior:
1. Compile cmucl
2. Look at compile-lisp.log ...## Describe the bug
There's a compiler warning that in linux-os.lisp, `get-page-size` is calling the unknown function `unix:unix-getpagesize`
## To Reproduce
Steps to reproduce the behavior:
1. Compile cmucl
2. Look at compile-lisp.log at the end where there's a warning that `UNIX:UNIX-GETPAGESIZE` is undefined.
## Expected behavior
There shouldn't be a warning
## Desktop (please complete the following information):
- OS: Linux
- Version: 21e
## Additional context
This is related to #257 because of the warning. We should probably
remove `get-page-size` from linux-os.lisp; it should be using
`get-page-size` from os.lisp.
A disassembly of `get-page-size` does show that we're using
`os_get_page_size`, so linux is using the version from os.lisp.
We probably missed this when fixing #180.SnapshotRaymond ToyRaymond Toyhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/256(loop for var nil from 1 to 2 ...) signals error2024-02-14T19:46:53ZRaymond Toy(loop for var nil from 1 to 2 ...) signals error## Describe the bug
`(loop for var nil from 1 to 2 collect var)` signals an error but the
equivalent `(loop for var of-type nil from 1 to 2 collect var)` does not.
## To Reproduce
Steps to reproduce the behavior:
1. Evaluate `(loop for...## Describe the bug
`(loop for var nil from 1 to 2 collect var)` signals an error but the
equivalent `(loop for var of-type nil from 1 to 2 collect var)` does not.
## To Reproduce
Steps to reproduce the behavior:
1. Evaluate `(loop for var nil from 1 to 2 collect var)` to see the error
2. Evaluate `(loop for var of-type nil from 1 to 2 collect var)` which
produces `(1 2)`.
## Expected behavior
Both should work.
## Desktop (please complete the following information):
- OS: All
- Version: 21e
## Additional context
It's not really clear what a type of `NIL` means in the context of
loop. But since `of-type` works, we should be consistent since the
forms are supposed to be equivalent.SnapshotRaymond ToyRaymond Toyhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/251c-call:char should have the same signedness as C char2023-09-05T00:06:05ZRaymond Toyc-call:char should have the same signedness as C char## Describe the bug
Currently `c-call:char` is a signed char. But to match C, `c-call:char` should have the same signedness as a C `char`. In particular, this means it should be unsigned for RISC-V, PowerPC, and ARM (among others). (S...## Describe the bug
Currently `c-call:char` is a signed char. But to match C, `c-call:char` should have the same signedness as a C `char`. In particular, this means it should be unsigned for RISC-V, PowerPC, and ARM (among others). (See https://gitlab.common-lisp.net/cmucl/cmucl/-/merge_requests/157#note_12484).
## Expected behavior
`c-call:char` should match C `char` signedness.
## Desktop (please complete the following information):
- OS: All
- Version: 21e (and earlier)https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/248Funny disassembly with capital D2023-07-24T21:53:48ZRaymond ToyFunny disassembly with capital D## Describe the bug
Cmucl prints out the movsd (string) instruction in a funny way.
## To Reproduce
Steps to reproduce the behavior:
1. Compile
```
(defun foo (a b &rest c)
(list a b c))
```
2. Look at the disassembly.
3. You'll see
`...## Describe the bug
Cmucl prints out the movsd (string) instruction in a funny way.
## To Reproduce
Steps to reproduce the behavior:
1. Compile
```
(defun foo (a b &rest c)
(list a b c))
```
2. Look at the disassembly.
3. You'll see
```
1ef: push esi
1f0: lea edi, [esp+#x8]
1f4: mov esi, ebp
1f6: sub esi, ebx
1f8: shr ecx, #x2
1fb: repne
1fc: movsD
```
## Expected behavior
The instruction should be `movsd`. (It's super confusing that movsd can mean move a doubleword from one address to another, or it can mean move a scalar double precision value.)
## Desktop (please complete the following information):
- OS: Linux and probably all x86 oses
- Version: 21e and probably much earlierSnapshot-2023-08