🚀 go-pugleaf

I recently tried building CScheme 6.1.2 on a pmax (DecStation 3100).  When
I defined UNSIGNED_SHIFT, scheme would die with an illegal type code in
gc_loop.  Not defining this symbol made the problem go away.  This happened
repeatably, though by changing what I did in scheme (from the usual cold-load
stuff) I could change when the illegal type code appeared and what it was.
In no case did the illegal type code have it's high-order (sign) bit on.

This is highly peculiar, for at least the following reasons:
 1) UNSIGNED_SHIFT works fine on a mipsfair (DecServer 5400), which should
    be essentially the same.
 2) Wsize tells me that UNSIGNED_SHIFT should work.
 3) The 7.0.0 beta release comes with a pmax configuration, complete with
    UNSIGNED_SHIFT.
 4) The only thing that UNSIGNED_SHIFT controlls is whether the shifted-down
    type code gets masked with 0xFF in case it was sign-extended.  However,
    none of the type codes currently in use has the high-order bit on (since
    fewer than 128 are defined).  Thus, it should be irrelevant whether
    sign extension happens or not.  I confirmed this by (on the mipsfair)
    changing the OBJECT_TYPE macro to explicitly force sign extension, by
    casting the pointer to a *signed* long before shifting.  Sure enough, it
    still works fine.

Although scheme is now running, I am troubled by this both because I may
be paying a performance penalty for masking and also because anything that is
this peculiar may be hiding a bigger problem.

So, at long last, my question: has anyone else seen anything like this, ever?
What turned out to be the cause?

Thanks very much.