Hello all,
I downloaded the most recent version of gpc, available at ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/ (gpc-980511) and I also got gcc-2.8.1. I tried to make gpc on an RS/6000 with AIX4.1.4, using gnu make 3.76. This is the result at a certain stage during the make:
../../xgpc -B../../ --automake -c -DGPC -Wall -Wpointer-arith -Wmissing-prototy pes -Wmissing-declarations -g -O2 -I. -I../.. -I/backup/gnu/gcc-2.8.1/p/rts/.. /.. -I/backup/gnu/gcc-2.8.1/p/rts/../../config rts-base.p rts-base.p:56: warning: no previous prototype for `__init_Rts_base' xgpc: Internal compiler error: program gpc1 got fatal signal 6 gmake[1]: *** [rts-base.o] Error 1 gmake[1]: Leaving directory `/backup/gnu/gcc-2.8.1/p/rts' gmake: *** [libgpc.a] Error 2
Again, an Internal Compiler Error seems to be the problem, just as it was the case with gpc-971001.
My debugger can't find much useful information in the core. A "where" just shows me this:
__start() at 0x100001c8
How do I solve this problem????????????
Please reply by mail as I'm not yet subscribed to the mailing list.
Nick Cremelie
According to Nick Cremelie:
../../xgpc -B../../ --automake -c -DGPC -Wall -Wpointer-arith -Wmissing-prototy pes -Wmissing-declarations -g -O2 -I. -I../.. -I/backup/gnu/gcc-2.8.1/p/rts/.. /.. -I/backup/gnu/gcc-2.8.1/p/rts/../../config rts-base.p rts-base.p:56: warning: no previous prototype for `__init_Rts_base' xgpc: Internal compiler error: program gpc1 got fatal signal 6
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.
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.
Thank you for reporting the problem,
Peter
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.
According to Nick Cremelie:
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
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.;-)
Peter
PS: Please reply via the list because there are certainly other AIX users following this discussion with high interest.
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
According to Nick Cremelie:
Nothing changes, I still get the same nasty Internal Compiler Error line. The problem might be not that simple...
Okay, so I see no other way out than remote debugging ... :-(
Please try to find out where in the GPC source the crash occurs. If you have no other possibility to do so, please add lines like
fprintf (stderr, "1\n");
in `parse.y', between the C lines in `implicit_module_constructor'. If it turns out that the crash occurs in, say, `start_function()', use the same method to find out where in `start_function()', and so on. (If somebody donates me an AIX workstation, I can do it for you.;-)-:
[...] 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.
According to `-dy', it occurs while compiling the unit constructor (an empty one in the case of `rts-base.p') which is at the end of the unit, but still inside the actual compilation (in contrast to some cleanup).
Peter
Okay, so I see no other way out than remote debugging ... :-(
I pulled in a binary of gdb this morning, but (probably since I'm not familiar with it) I didn't get anything useful out of that. I examined the core with the aix debugger and this is what I see with the command "where" (this command shows where the program stops). Output is below (ignore the "= internal error" parts, they originate from the fact that the aix debugger does not understand everything that gcc added in the gpc1 executable).
---begin--- [using memory image in core]
IOT/Abort trap in raise at 0xd0077eac 0xd0077eac (raise+0x20) 80410014 lwz r2,0x14(r1) (dbx) where raise(??) at 0xd0077eac abort() at 0xd0019a70 unnamed block $b2307, line 4027 in "rs6000.c" 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 0x20080a2c), line 3647 in "toplev.c" finish_function(??), line 8734 in "gpc-decl.c" yyparse(), line 6628 in "parse.y" compile_file(name = internal error: assertion failed at line 947 in file frame.c
(nil)), line 2494 in "toplev.c" main(argc = 15, argv = 0x2ff227cc, envp = 0xffffffff), line 4377 in "toplev.c" ---end---
So what do we learn from that?........
Nick
P.S. when replying to the list please cc to me (cremelie@elis.rug.ac.be)
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 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.
Hmmm...as I wrote earlier, this problem is solved thanks to the patch that Klaus proposed. Why would you still need the info requested above?
Nick
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
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
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...).
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
Toby
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
-
Klaus Espenlaub -
Nick Cremelie -
Peter Gerwinski -
Robert P. Ewing