Interestingly, the error is not deterministic, ie, after running the command several times the program gets compiled. When that happens, and ff the file test.o is not deleted, further attempts to compile run succesfully.

Change History (20)

This looks serious, as in a release blocker. And it looks like it's the same as the problem I've been encountering when building on Window: ​http://www.haskell.org/pipermail/ghc-devs/2014-March/004189.html. Notice the crash happens for me after a couple of CPSZ messages have come out, same as reported above on StackOverflow.

But hello-world failing is much easier to track down than GHC itself failing.

After testing and investigation, we believe this is related to #8834 - but also, we can't easily reproduce this. So I'm lowering the priority and marking this to 7.8.2. I will thoroughly test with the Windows distribution (coming soon).

@Simon, I've tried sprinkling some NOINLINE to see if it has any effect on pressure the codegen might be under - indeed, if I sprinkle a few NOINLINE here and there like on genCCall (a massive piece of code in its own right), then System.Time does compile, but DPH fails to compile later on:

I will note that in the example I posted in the other comment, a292_rFAj at the STG level - which roughly corresponds to stmtToInstrs - is absolutely massive - by itself, it's on the order of 24,000 lines of intermediate code long. X86.CodeGen really only exports cmmTopCodeGen, so it probably goes to town on the module, inlining like crazy, since stmtToInstrs is at the heart of it.

As a temporary workaround could we simply increase reserved *and* committed stack size in an executable's header making GHC invoke linker with right options when producing executables - something like -optl-Xlinker -optl--stack=0x800000,0x800000? This would make things more or less like they are under Linux/OSX. Or we need to access intermediate addresses anyway? If so, to speed things up we could use already existent __chkstk function.

windows: Fix #8870
This bumps the amount of default reserved and committed stack for GHC
executables to 8mb, to work around #8870. A proper fix should happen in
7.8.2
See note [Windows stack usage] in SysTools for the details.
Signed-off-by: Austin Seipp <[email protected]>