A bogus flag was propagated to closure information. This flag
was ignored by the validator, but not `zo-parse'. Make the validator
reject the bogus flag, too, while fixing the compiler.
This one is related to shifting type info when the closure is
made smaller due to lifting of something that used to be in
the closure. The `games/pousse/robot' module exposed the bug.
This is another old bug that could have caused validation failures
with flonums, but it showed up with fixnum tracking because fixnums
are more common (e.g., from `string-length').
There were really two bugs: information installed at the
wrong offet in one place, and a failure to detect that information
should be propagated in a different place. Fixing both avoids
a validation problem with `html/sgml-reader'.
Instead of keeping offsets in terms of `double's, keep it in
terms of bytes. This change is a step toward putting other kinds
of values on the flostack, such as extended-precision floats.
The last argument in a self-tail cal is treated specially and
not immediately stored on the "runstack". Space was formerly
allocated for it, though, and under certain circumstances
that space was not initialized. I think a combination of thread
timing, GC timing, and flonum boxing could potentially lead to a
crash (but constructing a test case is really difficult).
The scheme_generate_arith() function effectively had its own
copy of of the general scheme_generate_two_args() function that
predates the general one. Using scheme_generate_two_args()
instead simplifies and clarifies the code.
Track fixnum results in the same way as flonum results to enable
unboxing, if that turns out to be useful. The intent of the change,
though, is to support other types in the future, such as "extnums".
The output `raco decompile' no longer includes `#%in', `#%flonum',
etc., annotations, which are mostly obvious and difficult to
keep in sync with the implementation. A local-binding name now
reflects a known type, however.
The change includes a bug repair for he bytecode compiler that
is independent of the generalization (i.e., the new test case
triggered the old problem using flonums).
This appears to be an old bug where a check and use are misordered, so
I'm not sure why it hasn't caused more trouble before, but it depends
on a GC happening at the right time.
Closes PR 13245
The JIT was pessimistically using 64-bit jumps for long branches
or any jump between code that is allocated at different times.
Normally, though, code allocation stays within the same 32-bit
range of the heap, so stick to 32-bit jumps until forced by
allocation addresses to use 64-bit jump targets.
In `(if (pair? x) E1 E2)', convert `(car x)' in E1 to
`(unsafe-car x)', and similarly for `(cdr x)'. Also,
`(begin (car x) (cdr x))' converts to `(begin (car x)
(unsafe-cdr x))' since `(car x)' implies a `pair?' test
on `x'.
More consistent clearing avoids a kind of space unsafety. There's just
one buffer per thread, so it's difficult to turn non-clearing into
a detectable leak (I wasn't abel to construct an example), but it
might be possible. More practically, failing to clear the buffer
can make it difficult to debug memory use.
The scheme_is_multiprocessor() function wasn't the right guard
for whether to use a locking compare-and-swap instruction; any
use of pthread-based futures needs the compare-and-swap.
Merge to v5.3.1
