> > 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 _______________________________________________ Glasgow-haskell-users mailing list [email protected] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
