Well, I figured it out myself in the end... it's gcc dodginess :/
numberToInt checks the number that's been read against minBound :: Int. In the 64-bit STG C code this ends up being:
_Cak7_=(-9223372036854775808)<=(I_)(R1.p[1]);
If I were to read the gcc warnings it would say:
Text/Read/Lex.hc:40: warning: decimal constant is so large that it is unsigned
and it seems to make a dodgy optimisation on that basis.
If I change the constant to -(2^63-1) instead of -2^63 it works, and without the warning message. Which seems like a compiler bug to me, since -2^63 is a valid 64-bit signed number. I'll see what the gcc folks have to say.
I've had similar problems before with minInt. I seem to recall that the C standard doesn't guarantee that this constant is representable in the int type: I think it has to do with the fact that the C standard doesn't proscribe 2's complement arithmetic, and in 1's complement you can't fit -2^63 in an int. Cheers, Simon