So I just upgraded to 7, and on compiling I got: /var/folders/++/+++c0U++6+0++4RjPqRgNE++8+c/-Tmp-/ghc88373_0/ghc88373_1.s:43:0: suffix or operands invalid for `push' /var/folders/++/+++c0U++6+0++4RjPqRgNE++8+c/-Tmp-/ghc88373_0/ghc88373_1.s:47:0: suffix or operands invalid for `push' ... etc. Some digging revealed that it was actually in the compilation of a *_stub.c file, and the underlying problem is thus: This is OS X 10.6. For various reasons, my app is compiled 32 bit, and I'm explicitly passing '-optc-m32 -opta-m32 -optl-m32' to ghc. Previously, of course, this wasn't necessary since ghc always produced 32 bit code. But now there seems to be an issue with flag order. When ghc wants to compile the stub, it runs: g++ -x c ./Ui/RulerC_stub.c -o broken.s -m64 -fno-stack-protector -fno-common -U __PIC__ -D__PIC__ -v -S -Wimplicit -O -D__GLASGOW_HASKELL__=700 -DTABLES_NEXT_TO_CODE -ggdb -m32 ... rest of my flags Then it wants to assemble it: /Developer/usr/bin/gcc -m32 -I./Ui -Ifltk -I. -c broken.s -o ./Ui/RulerC_stub.o -m64 -fno-stack-protector So it looks like when compiling, the user flags go last, overriding the new default -m64. But when assembling, they go first, and are overidden. This seems like an easy fix, I imagine it's just constructing the cmdline inconsistently. Is there a way for me to influence how it constructs the cmdline for gcc for stubs? I mean, without recompiling ghc. I'm supposed to be able to get ghc to compile 32 bit, right? It also seems odd to me that it's compiled and assembled separately, but I suppose there must have been some reason for that. I guess I should have upgraded sooner to catch this back when there was a new ghc 7 release every week...