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 <args..>" manually gave a core dump from 'perl'. It didn't complain about parse errors or similar so my guess is that the code in itself is 5.005_03-compatible, the splitter is just triggering some bug in the perl machinery. I didn't think of writing down any details at the moment since changing to 5.8.4 'fixed' my problem. Perl 5.6.0 seems to be released 2000-Mar-22, demanding that people who build ghc have a perl that is no older than 5 years might be a reasonable first step?
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