cosmos72 / stmx

High performance Transactional Memory for Common Lisp
http://stmx.org/
241 stars 14 forks source link

Does not build - emit-skip issue #19

Closed quicklisp closed 4 years ago

quicklisp commented 4 years ago

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 references sb-vm::emit-skip.

Build log here: http://report.quicklisp.org/2020-02-24/failure-report/stmx.html#stmx

cosmos72 commented 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.

cosmos72 commented 4 years ago

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