Hi Christopher,

I don't know how Racket does it but I wrote my own interpreters with GC and there,
you have to know where references to objects can be found.

In this case the references can be on the stack of the C functions as long as
they are running.

It turns out that in the version of gcc we use to compile racket, the sign checker
for 128 bit floats (__signbitf128) is not a builtin (it's not emitting just an immediate
assembly instruction) but rather is a C function - but the caller in Racket is marked
as "don't bother looking for object references in there".  As Racket supports
arbitrary-precision numbers, a number might be an object and a part of that object
might have been passed to __signbitf128.  If the GC runs, it might be killing
that object while it's still used inside __signbitf128 (in a loop or something).

So the possible fixes are:

(1) Do not use __signbitf128 (that is, "signbit") - there's a fallback which uses
primitive operations that are guaranteed to be builtin (/).  That's the non-invasive
very safe change (s|MZ_IS_NEG_ZERO|MZ_IS_NEG_ZERO_DONOTUSE| at one place) - since
from the outside the function would look exactly the same as if it used
__signbitf128 - it's a leaf.

(2) Remove the nogcing marker.  That's the more invasive change which slightly
changes how the GC root set looks - it should be safe enough anyway (if there
are no bugs in the GC root set lookup :) )

(3) Use gcc-7.  Given that Racket users probably use FFI to load other C libraries
which aren't compiled with gcc-7, let's not do that.

Please note that I didn't write Racket so take it with a grain of salt.