Closed quicklisp closed 4 years ago
Found. It's an internal change in sbcl, which confuses stmx detection of x86-64 instructions 'xbegin' 'xend' ... that were added to sbcl 1.3.4 (previously, these instructions were defined by stmx itself).
Such detection code is obviously examining sbcl internals in unsupported ways, and infact it keeps breaking (it already happened with sbcl 1.4.10, as you reported in issue #14)
I guess it must be rewritten as "assume that sbcl >= 1.3.4 defines 'xbegin' 'xend'... and assume that sbcl < 1.3.4 does not define them".
Or, more brutally, drop support for sbcl < 1.3.4 - although I'd rather preserve it, as I have no idea whether it's still actively used.
Fixed, both in master branch (commit f8de8cc784585eeb917d5474af5b8f9510fa4bd6) and in stable branch pulled by quicklisp (commit bf11fcd4a01e3bf424f0e6330dcdda7b103d01f1)
The solution I applied is "assume that sbcl >= 1.3.4 defines 'xbegin' 'xend'... and assume that sbcl < 1.3.4 does not define them" instead of inspecting SBCL internals
Same as (or similar to) #17 - with the latest SBCL git checkout, and the latest stmx checkout, I get a failure due to package locks on sb-vm.
It looks to me like
(stmx.asm::compile-if-instruction-defined 'xbegin)
evaluates to(:OR)
and combined with#-
it tries to read the form that referencessb-vm::emit-skip
.Build log here: http://report.quicklisp.org/2020-02-24/failure-report/stmx.html#stmx