I would have thought '437490' ("Fix discrepancies in handling toplevel forms") to be a more likely culprit.  The parallel-load test has no toplevel SETQ of any kind, either for a special or global var.
At least, I've gotten a test to hang on "fix discrepancies" but not on "setq global is fopcompilable" after hundreds of iterations.

So my guess would be that using compiler macros makes fewer things fopcompilable which makes more things need to produce machine code, and I think there's a probably-pre-existing threading issue that is exposed.  i.e. the comment at the top of load.lisp says "
Because this code is mutually recursive with the compiler, we use the **WORLD-LOCK**" which is pretty clearly not true. It is touching stuff the compiler touches, but _without_ protecting itself.

Are you absolutely certain you could make it hang with the "setq global" and not the next change too? 

On Mon, Aug 11, 2014 at 8:04 PM, Jan Moringen <jmoringe@techfak.uni-bielefeld.de> wrote:

as reported by reb and myself in #sbcl, the test
load.impure.lisp:parallel-fasl-load sometimes hangs when the
sb-safepoint feature is enabled. I observed this on Linux x86 and Linux
x86_64. It may or may not occur on MacOS (our MacOS build slave has
become so unreliable that I had to stop using it).

I bisected the problem to this commit (with some remaining uncertainty
due to the hanging not occurring deterministically, but the previous
commit passed the test 100 times, so is at least unlikely to be bad):

        commit 0ad7c5ca279e332b616666e92782ca1ec8e15f16
        Author: Douglas Katzman <dougk@google.com>
        Date:   Tue Jul 29 08:54:26 2014 -0400

            SETQ of a :global variable is fopcompilable.

These are the commits I tested more thoroughly after having formed the
initial suspicion:

        bad  623d15fa9e04f958ad597ffd10b7170edbdcc87e Type-class lint removal
        bad  71e1bd4be8be59a647763eb346e81e32192ebcab Implement another atomic globaldb (INFO) primitive operation.
        bad  437490ed66172686a3f9d1d264b66fa2cfb2bb8e Fix discrepancies in handling toplevel forms per CLHS
        bad  0ad7c5ca279e332b616666e92782ca1ec8e15f16 SETQ of a :global variable is fopcompilable.
        good 447119c2d244f6463226eac3e49d57b72df34f78 x86[-64]: fix %MORE-ARG-VALUES for 'skip' operand other than zero

The script I used for bisecting is attached. It should be able to
reproduce the problem, maybe after increasing the number of repetitions.

Kind regards,


Sbcl-devel mailing list