cmucl issueshttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues2024-03-25T15:48:02Zhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/292Add interface to mkstemp2024-03-25T15:48:02ZRaymond ToyAdd interface to mkstemp## Describe the feature
Add an interface to [mkstemp](https://pubs.opengroup.org/onlinepubs/009604499/functions/mkstemp.html)
## Is there a prototype?
None currently, but shouldn't be too hard to make one.
## Describe the feature in mo...## Describe the feature
Add an interface to [mkstemp](https://pubs.opengroup.org/onlinepubs/009604499/functions/mkstemp.html)
## Is there a prototype?
None currently, but shouldn't be too hard to make one.
## Describe the feature in more detail
It would be useful to provide this interface. Both clisp and ecl
provide such a Lisp function. Maybe also include an interface to
[tempnam](https://pubs.opengroup.org/onlinepubs/009604599/functions/tempnam.html)
too? Neither clisp nor ecl appear to provide `tempnam`.
Turns out that in the embedded-c contrib, there is an example of using
embedded C with `tempnam`. It also defines `mkdtemp` too.https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/291Pprint handler-case better?2024-03-27T14:20:21ZRaymond ToyPprint handler-case better?## Describe the feature
Consider the form:
```
(defun careful-expand-macro (fun form)
(handler-case (invoke-macroexpand-hook fun form *lexical-environment*)
(error (condition)
(compiler-error "(during macroexpansion)~%...## Describe the feature
Consider the form:
```
(defun careful-expand-macro (fun form)
(handler-case (invoke-macroexpand-hook fun form *lexical-environment*)
(error (condition)
(compiler-error "(during macroexpansion)~%~A"
condition))))
```
When cmucl pprints it, we get:
```
* (pprint '(defun careful-expand-macro (fun form)
(handler-case (invoke-macroexpand-hook fun form *lexical-environment*)
(error (condition)
(compiler-error "(during macroexpansion)~%~A"
condition)))))
(DEFUN CAREFUL-EXPAND-MACRO (FUN FORM)
(HANDLER-CASE (INVOKE-MACROEXPAND-HOOK FUN FORM *LEXICAL-ENVIRONMENT*)
(ERROR (CONDITION)
(COMPILER-ERROR "(during macroexpansion)~%~A" CONDITION))))
```
I think it looks better if the result were:
```
(DEFUN CAREFUL-EXPAND-MACRO (FUN FORM)
(HANDLER-CASE (INVOKE-MACROEXPAND-HOOK FUN FORM *LEXICAL-ENVIRONMENT*)
(ERROR (CONDITION)
(COMPILER-ERROR "(during macroexpansion)~%~A" CONDITION))))
```
That is, the body of the `error` shouldn't be lined up with the arg. It should be indented 2 spaces.
Looking at some examples in the code base, there's a mixe of styles. Some is like the former and some like the latter.
## Is there a prototype?
No. But it should be hard to create a pprinter for this.Raymond ToyRaymond Toyhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/290Pprint with-float-traps-masked better2024-03-25T15:17:03ZRaymond ToyPprint with-float-traps-masked better## Describe the feature
Cmucl pprints the form
```
(with-float-traps-masked (:underflow)
(let* ((ratio (/ (* (expt 10 exponent) number)
divisor))
(result (coerce ratio float-format)))
(when (and (zerop result) ...## Describe the feature
Cmucl pprints the form
```
(with-float-traps-masked (:underflow)
(let* ((ratio (/ (* (expt 10 exponent) number)
divisor))
(result (coerce ratio float-format)))
(when (and (zerop result) (not (zerop number)))
;; The number we've read is so small that it gets
;; converted to 0.0, but is not actually zero. Signal an
;; error. See CLHS 2.3.1.1.
(error _"Underflow"))
result))
```
as
```
* (pprint '(with-float-traps-masked (:underflow)
(let* ((ratio (/ (* (expt 10 exponent) number)
divisor))
(result (coerce ratio float-format)))
(when (and (zerop result) (not (zerop number)))
;; The number we've read is so small that it gets
;; converted to 0.0, but is not actually zero. Signal an
;; error. See CLHS 2.3.1.1.
(error "Underflow"))
result)))
(WITH-FLOAT-TRAPS-MASKED (:UNDERFLOW)
(LET* ((RATIO
(/ (* (EXPT 10 EXPONENT) NUMBER) DIVISOR))
(RESULT (COERCE RATIO FLOAT-FORMAT)))
(WHEN (AND (ZEROP RESULT) (NOT (ZEROP NUMBER)))
(ERROR "Underflow"))
RESULT))
```
This looks funny.
## Is there a prototype?
No prototype, but shouldn't be too hard to make it work by adding a
new pprinter to pprint.lisp. We should do the same formatting for
`with-float-traps-enabled` too.https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/289Unboxed 64-bit arithmetic2024-03-26T05:06:30ZCarl ShapiroUnboxed 64-bit arithmetic## Describe the feature
CMUCL has support for unboxed arithmetic including values of type `(signed-byte 32)` and `(unsigned-byte 32)`. This support should be extended to include `(signed-byte 64)` and `(unsigned-byte 64)`.
## Is there ...## Describe the feature
CMUCL has support for unboxed arithmetic including values of type `(signed-byte 32)` and `(unsigned-byte 32)`. This support should be extended to include `(signed-byte 64)` and `(unsigned-byte 64)`.
## Is there a prototype?
There is no complete prototype but the support for 32-bit is a partial prototype.
## Describe the feature in more detail
The basic idea is to add compiler transformations to support unboxed double word arithmetic. Looking toward the future, this could be used to support unboxed 128-bit arithmetic on a 64-bit machine. This will benefit any application that needs to perform successive operations on 64-bit values and the performance overhead of allocating bignum objects for the intermediate values is undesirable.https://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/287Clean up make-float-aux due to #2772024-03-26T14:48:09ZRaymond ToyClean up make-float-aux due to #277In `make-float-aux`, we have this bit of code:
```
(when (and (zerop result) (not (zerop number)))
;; The number we've read is so small that it gets
;; converted to 0.0, but is not actually zero. In this
;; case, we wa...In `make-float-aux`, we have this bit of code:
```
(when (and (zerop result) (not (zerop number)))
;; The number we've read is so small that it gets
;; converted to 0.0, but is not actually zero. In this
;; case, we want to round such small numbers to
;; least-positive-foo-float. If it's still too small, we
;; want to signal an error saying that we can't really
;; convert it because the exponent is too small.
;; See CLHS 2.3.1.1.
(let ((float-limit (ecase float-format
((short-float single-float)
least-positive-single-float)
(double-float
least-positive-double-float)
#+double-double
(double-double-float
ext:least-positive-double-double-float))))
(if (>= (* 2 ratio) float-limit)
(setf result float-limit)
(error _"Underflow"))))
```
However, since #277 was fixed, we return a correctly rounded value for `result`. Hence the code testing `ratio` against `float-limit` isn't needed. If `result` is 0 and `number` is not zero, then the number definitely can't be represented as a float. We can remove all of that `float-limit` stuff and just throw an error.SnapshotRaymond ToyRaymond Toyhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/28664-bit cmucl2024-03-22T22:24:13ZRaymond Toy64-bit cmucl## Describe the feature
Make cmucl be a 64-bit app so it can run on modern OSes without having to load 32-bit libraries and tools.
## Is there a prototype?
No.## Describe the feature
Make cmucl be a 64-bit app so it can run on modern OSes without having to load 32-bit libraries and tools.
## Is there a prototype?
No.https://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/284Microoptimize integer-length for signed-byte 32 and unsigned-byte 32 args2024-03-23T03:09:43ZRaymond ToyMicrooptimize integer-length for signed-byte 32 and unsigned-byte 32 argsWhen implementing the fix for #283, we take advantage of the fact that `BSR` does not modify the destination register when the source is 0. We can optimize the `signed-byte-32-int-len` vop using this fact too. It gets rid of an extra j...When implementing the fix for #283, we take advantage of the fact that `BSR` does not modify the destination register when the source is 0. We can optimize the `signed-byte-32-int-len` vop using this fact too. It gets rid of an extra jump and an extra instruction.
We can also optimize the unsigned-byte 32 version by assuming that the `BSR` operation copies the source value to the destination register when the source is 0. Gcc, LLVM, and MSVC generate code assuming this happens.SnapshotRaymond 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/281Optimize xoroshiro128** generator2024-03-15T20:50:36ZRaymond ToyOptimize xoroshiro128** generatorAs mentioned in https://gitlab.common-lisp.net/cmucl/cmucl/-/merge_requests/192#note_13890 and nearby comments, our implementation via the VOP is quite a bit slower than the equivalent C code.
We should look into seeing if we can speed ...As mentioned in https://gitlab.common-lisp.net/cmucl/cmucl/-/merge_requests/192#note_13890 and nearby comments, our implementation via the VOP is quite a bit slower than the equivalent C code.
We should look into seeing if we can speed up the implementation. The C code generates reasonably compact code that is quite a bit faster than our SSE2 implementation.
The pure Lisp implementation is about 4.5 times slower than the VOP. Not great but not terrible, considering that I didn't really try too hard to optimize the speed. It would be nice if the pure Lisp version were comparable to the VOP.https://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/278Add some more debugging prints to gencgc2024-03-08T15:32:08ZRaymond ToyAdd some more debugging prints to gencgcWhile debugging !188, more prints in gencgc were useful. I think they're generally useful for debugging, so let's add these prints.While debugging !188, more prints in gencgc were useful. I think they're generally useful for debugging, so let's add these prints.SnapshotRaymond ToyRaymond Toyhttps://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/276xoroshiro RNG doesn't match reference2024-03-22T16:35:36ZRaymond Toyxoroshiro RNG doesn't match referenceOur xoroshiro128+ generator has a link to the [C source code](http://xoroshiro.di.unimi.it/xoroshiro128plus.c). However, if you follow that link, the actual C code doesn't match the C code we pasted in as a [comment](src/code/rand-xoros...Our xoroshiro128+ generator has a link to the [C source code](http://xoroshiro.di.unimi.it/xoroshiro128plus.c). However, if you follow that link, the actual C code doesn't match the C code we pasted in as a [comment](src/code/rand-xoroshiro.lisp#L242).
Not sure what happened, but I suspect we were using an early version that got updated at some point. Modifying it shouldn't be too hard.
But if we're modifying the RNG (again), perhaps we should update to [xoroshiro256++](https://prng.di.unimi.it/xoshiro256plusplus.c). I don't think it would be terribly hard to implement this. There are 256 bits of state vs the 128 bits we currently have.
Of course, we have an issue that we don't have a current sparc box to test with. Whatever we do will be for x86 only. At least for now.https://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/273REBOOT2024-02-03T00:37:30ZAlexander FedorovREBOOT