Although a future thread used an atomic compare-and-swap to
set "is a list" or "not a list" flag on pairs via the
JIT-implemented `list?', the hashing function in the runtime
thread did not; as a result, it might be possible to lose
a hash code due to cache inconsistency (although I'm not
sure it's actually possible, and I couldn't trigger a problem
with a test). Most of the changes are related to using
an atomic compare-and-swap when setting a hash code, as
well as clean-ups to related code. Processor-count tests
avoid using atomic compare-and-swap on uniprocessors, which
might not support the relevant machine instructions.
As significantly, the compare-and-swap operation for the
JIT-implemented `list?' did not actually set flags on
a pair that has a hash code. This could lead to `list?'
tests that were not constant time (but only if the relevant
pair's `eq?' hash code had been used previously).
The specific error reported by CopyFileW doesn't seem
to be documented. It's unclear whether Racket's old test
for ERROR_EXISTS_ALREADY was the wrong choice (as opposed
to ERROR_FILE_EXISTS) or whether some Windows versions
use it; we test for both for now.
Also, improve error reporting when an errno or
GetLastError() value is available.
Closes PR 12074
Merge to 5.1.2
This reverts commit 2afff3d210.
This commit caused real->double-flonum to have a different behavior
when jitted as opposed to interpreted, and caused real->single-flonum
to break in some cases.
Merge to 5.1.2.
A recent (weeks-old) JIT change set one of a function's code
pointers to NULL to indicate that JIT-compilation of the
function is in progress, but that breaks futures. Set the
code pointer to a different not-yet-ready function, instead.
Merge to 5.1.2
Closes PR 12037
There were two:
* new: after finding a hash code, the key wasn't
always checked to be `eq?' to the desired key
* old: the hash code wan't downshifted by 2, so
changes in the low two bits (like when a pair
is determined to start a list) could break
lookup
Merge to 5.1.2
Use the new functions in `syntax-case'; the benefit is small, and
it's mostly useful as hint to the optimizer that the operation
can be dropped if the result isn't used
