Hello all,

Regarding my "xgpc: Internal compiler error: program gpc1 got fatal signal 6", Peter Gerwinski wrote:

Please try to compile rts-base.p manually, giving the additional option `-dY'. This will dump the source to `stderr' thus showing us after which line the error occured.

Result:

---begin--- unit RTS_Base;

interface

const

Bits_Big_Endian = {$ifdef __BITS_LITTLE_ENDIAN__}{$else} {$ifdef __BITS_BIG_ENDIAN__} True {$else}{$endif} {$endif};

Bytes_Big_Endian = {$ifdef __BYTES_LITTLE_ENDIAN__}{$else} {$ifdef __BYTES_BIG_ENDIAN__} True {$else}{$endif} {$endif};

Words_Big_Endian = {$ifdef __WORDS_LITTLE_ENDIAN__}{$else} {$ifdef __WORDS_BIG_ENDIAN__} True {$else}{$endif} {$endif};

Need_Word_Alignment = {$ifdef __NEED_WORD_ALIGNMENT__}{$else} False {$endif};

implementation

end.rts-base.p:56: warning: no previous prototype for `__init_Rts_base' xgpc: Internal compiler error: program gpc1 got fatal signal 6 ---end---

After that, please retry with `-dy' instead of `-dY' which will dump - a lot of - parser debugging information to `stderr'. In both cases, please post the last, say, 10 lines of the output to this list.

Result:

---begin--- Entering state 1206 Reducing via rule 962 (line 6508), import_part any_declaration_part -> unit_imp lementation state stack now 0 3 13 190 216 256 313 498 612 724 842 Entering state 1071 Next token is 268 (END) Reducing via rule 988 (line 6708), -> @70 rts-base.p:56: warning: no previous prototype for `__init_Rts_base' state stack now 0 3 13 190 216 256 313 498 612 724 842 1071 Entering state 715 Reducing via rule 948 (line 6399), -> pushlevel1 state stack now 0 3 13 190 216 256 313 498 612 724 842 1071 715 Entering state 830 Reducing via rule 989 (line 6736), -> @71 state stack now 0 3 13 190 216 256 313 498 612 724 842 1071 715 830 Entering state 1066 Reducing via rule 950 (line 6417), -> poplevel1 state stack now 0 3 13 190 216 256 313 498 612 724 842 1071 715 830 1066 Entering state 1194 Reducing via rule 990 (line 6743), @70 pushlevel1 @71 poplevel1 -> implicit_mod ule_constructor xgpc: Internal compiler error: program gpc1 got fatal signal 6 ---end---

Another note: configure determined that our system is a powerpc-ibm-aix4.1.4. I also tried building the compiler after a `configure rs6000-ibm-aix', but the same error was generated. Are we the first ones to try gpc on aix? I have a group of fanatic pascal programmers here and they want a compiler running on different systems to increase portability. I was (still am) hoping that gpc brings the solution...

Nick Cremelie

P.S. again, please reply by e-mail as I'm not subscribed to the list yet.

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.

BTW, is there anyone who has a gpc binary for aix? I could try that one and see what happens...

Nick Cremelie

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

Just forwarded some better output of the debugger to Peter, I asked him to dump it also on this mailing list (can someone subscribe me to it, please?).

Anyway, to answer your remarks:

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.

Files: -rw-r----- 1 root system 23979 Jul 01 17:47 core -rw-r----- 1 root system 1827 Jul 01 17:47 rts-base.pas.addressof -rw-r----- 1 root system 1827 Jul 01 17:47 rts-base.pas.bp -rw-r----- 1 root system 2516 Jul 01 17:47 rts-base.pas.combine -rw-r----- 1 root system 1912 Jul 01 17:47 rts-base.pas.cse -rw-r----- 1 root system 1911 Jul 01 17:47 rts-base.pas.cse2 -rw-r----- 1 root system 2917 Jul 01 17:47 rts-base.pas.flow -rw-r----- 1 root system 3281 Jul 01 17:47 rts-base.pas.greg -rw-r----- 1 root system 1663 Jul 01 17:47 rts-base.pas.jump -rw-r----- 1 root system 2538 Jul 01 17:47 rts-base.pas.jump2 -rw-r----- 1 root system 1858 Jul 01 17:47 rts-base.pas.loop -rw-r----- 1 root system 3081 Jul 01 17:47 rts-base.pas.lreg -rw-r----- 1 root system 2198 Jul 01 17:47 rts-base.pas.rtl -rw-r----- 1 root system 5271 Jul 01 17:47 rts-base.pas.sched -rw-r----- 1 root system 3970 Jul 01 17:47 rts-base.pas.sched2 -rw-r----- 1 root system 0 Jul 01 17:47 rts-base.pas.dbr -rw-r----- 1 root system 4603 Jul 01 17:47 rts_base.gpi

If I got your explanation well, I should compare .sched2 and .jump2. Well I don't see anything useful in these files, so I'll mail them to you (Klaus) and anyone else asking them.

Nick

According to Nick Cremelie:

[...] output_epilog(??, ??), line 4027 in "rs6000.c" final_end_function(??, ??, ??), line 1151 in "final.c" rest_of_compilation(decl = internal error: assertion failed at line 947 in file frame.c [...]

If you could call the function `debug_tree()' on the parameter `decl' of `rest_of_compilation()', it would be helpful if you posted the result here.

Peter

According to Robert P. Ewing:

I just installed gpc on an Indigo running irix5.3. The installation was easy (trivial?), but obviously it is not yet complete.

When try a test compile: gpc -o test test.p

What's the output of the following?

gpc -v -o test test.p

I get: gpc: installation problem, cannot exec 'as': No such file or directory.

Looking in the /usr/local/bin directory shows I have gpc, but nothing else (no as, no ld...).

Your system's `as', `ld' etc must be installed somewhere (e.g. in /usr/bin); please try to find out their place. It is also possible to use the GNU versions of those programs; in that case you have to `./configure' GPC with `--with-gnu-as' and/or `--with-gnu-ld' and to provide the corresponding packages.

Any idea where I can get binaries for these? My unix and c skills are pretty nil, and if there are binaries around, that would be ideal

I have not, but perhaps someone in this list has a ready GPC for irix-5.3?

Hope this helps, :-/

Peter