I had perl 5.005_03 first in my path, that made the splitter not work. Changing to a newer version made it work. Maybe a test could be added to configure to avoid too old versions of perl?
I'll be happy to - but I don't know exactly what version of Perl we require. Any clues? What went wrong with the splitter?
Sorry for the bad description of the error. I'll try again: The
problem I had was a failed build and a silent failure of the
splitter. No error message or similar, just a return. Poking around
with it and running "perl splitter
Needed a patch to build NCG. I tried to preserve as much of the previous structure in order to avoid introducing bugs, but I wasn't entirely successfull. I've attached the patch and would appreciate if someone could glance over it looking for obvious errors.
There are never any "obvious" errors in the NCG :-) I did glance over it, and it mostly looks like a straightforward change over to Cmm. Since your patch only touches code inside #ifdef sparc_TARGET_ARCH, which is currently broken anyway, I'm inclined to just merge it as-is.
That sounds good to me, a smaller diff would hopefully make my life easier. About the lack of sparc-support - is the problem that no active developers have access to sparc-machines any longer or is there simply no interest in sparc? If it is the former, contact me off list and I'll try to help out.
With this patch a bunch of array tests with WAY=normal fails, all in the same way:
Stack space overflow: current size 8388608 bytes. Use `+RTS -Ksize' to increase it.
Best guess is the code generated for a stack-check sequence is incorrect. Match up the assembly file (use -keep-s-file) with the Cmm (-ddump-opt-cmm) and see if you can spot the incorrect code. I can provide some gdb tips - let me know if you need more help.
Ahh, and here I was using -v5. This is much better. The stack-check sequence you are referring to, is that in Cmm represented by "if ((Sp + -12) < SpLim) goto <label>"? If that is the case, I can't find any errors in the asm produced. Any hints that would ease the burden of reading big chunks of assembler would be much appreciated!
Also, the codeGen tests are probably a better place to start (tests/ghc-regress/codeGen/should_run).
Ok, will look into this. / Peter