Nick Cremelie wrote:
What happens if you add a line with "begin" in front of the final "end." in `rts-base.p'? If this crashes as well, add some dummy Pascal statement (e.g. "repeat until true") between them and try again. (If not, we have found a workaround.;-)
Nothing changes, I still get the same nasty Internal Compiler Error line. The problem might be not that simple... I had exactly the same error after compiling gpc971001 (with that version, the build succeeded, I assume gpc was not used in that version to build itself?). I tried simple programs, large programs, but to no avail. I was under the impression that the compilation of the programs was actually carried out and that the crash always occurred during a final phase of the compilation.
This is what I'd guess, too. I really doubt that this call to abort() is anywhere in the pascal frontend. It's either some old backend bug or it's some bad code generated by the frontend, which causes the backend to crash.
It would be interesting if just the core file you get is - let's say - suboptimal of if the debugger you're using doesn't understand the debugging info gcc generates. Which debugger are you using? gdb? Some proprietary dbx? I made a similar experience with gdb on Sun SPARC machines - all core dumps had the stack contents mangled beyond recognition, but running the compiler in the debugger itself helped. Just use the command line printed when doing gpc -v <rest of the compilation parameters>. Set a breakpoint on abort (if you're in the right directory and using gdb, it already does that). Go. In most of my tests with gcc this provided a usable stack backtrace (try command bt), but of some code trashed the stack, it doesn't help much.
If this doesn't work for one reason or another, I'd have another try with the debugging dumps. GCC has heaps of options helping you to fill the unused space on your drive ;-)
I'd go for a "-da" session. You probably need a bit of disk space for about a dozen debugging dump files, but you can discard them after a bit of inspection. 1-2 Meg should be enough for
First of all, repeat the compilation with option "-da", and delete the "-dy" or "-dY" that may still be there in some Makefile. You should end up with quite a few rts-base.p.* files in the directory where rts-base.p resides (or in the current directory, I always forget).
Do a ls -l on this set of files and post it here. The sizes are interesting, because they tell us where in the code generation it crashed. The last non-zero length file with the suffix rtl, jump, cse, addressof, loop, cse2, bp, flow, combine, sched, lreg, greg, sched2, jump2, dbr, stack (in this order!) should be inspected and compared to the one with the previous suffix. There are some comments in the file, stating which function the code belongs to. Usually the last non-zero length file misses one.
Anyway, if this analysis is too much trouble for you, you can tar, gzip and uuencode all the dump files and send them to me via private mail (don't send them to the list unless someone else asks for them, it's a waste of bandwidth).
I don't know how well this works with Pascal code, but it's fine with C stuff crashing the compiler.
BTW, is there anyone who has a gpc binary for aix? I could try that one and see what happens...
Sorry, no. There used to be some dog slow AIX machine here at Uni, but I just checked today, and it's gone. So I cannot test.
Klaus