Nick Cremelie wrote:
And this is what gdb shows me (I think it's pretty much the same) ---begin--- GDB 4.16 (rs6000-ibm-aix4), Copyright 1996 Free Software Foundation, Inc... Core was generated by `gpc1'. Program terminated with signal 6, IOT/Abort trap. #0 0xd0077eac in raise () (gdb) bt #0 0xd0077eac in raise () #1 0xd0019a74 in abort () #2 0x1004f258 in output_epilog (file=0xf013f4c0, size=-1) at rs6000.c:4027 #3 0x10142664 in final_end_function (first=0x0, file=0xf013f4c0, optimize=-1) at final.c:1151 #4 0x10005548 in rest_of_compilation (decl=0x20080a2c) at toplev.c:3647 #5 0x100b8ce4 in finish_function (nested=0) at gpc-decl.c:8734 #6 0x1018dbc0 in yyparse () at parse.y:6628 #7 0x10003084 in compile_file (name=0x0) at toplev.c:2494 #8 0x10006624 in main (argc=15, argv=0x2ff227cc, envp=0xffffffff) at toplev.c:4377 #9 0x100001f4 in __start () ---end---
Apparently there's something not right in rs6000.c. What do you think?
I haven't read the previous stack dump closely enough, I think. And I think your analysis is correct. The code around line 4027 in rs6000.c looks like this: /* Language type. Unfortunately, there doesn't seem to be any official way to get this info, so we use language_string. C is 0. C++ is 9. No number defined for Obj-C, so use the value for C for now. */ if (! strcmp (language_string, "GNU C") || ! strcmp (language_string, "GNU Obj-C")) i = 0; else if (! strcmp (language_string, "GNU F77")) i = 1; else if (! strcmp (language_string, "GNU Ada")) i = 3; else if (! strcmp (language_string, "GNU Pascal")) i = 2; else if (! strcmp (language_string, "GNU C++")) i = 9; else abort (); fprintf (file, "%d,", i);
So here you go, abort! Who messed around with the language_string recently? This should be rather trivial to fix for Peter. The actual bug is in p/parse.c and is even documented. Just take the language_string hack for _IBMR2 out and your compiler should work. The "bug" is around line 360 in p/parse.c. Of course, to fix this, we need to change p/parse.y, being the source for parse.c. Nick, do you have bison installed on your machine? If not, you have to change p/parse.c by hand for a quick fix, and don't apply the p/parse.y patch below.
oops, just noticed that I forgot to add useful options to diff. I hope that the following works for you, Peter. If not, drop me a note. I got to run now, and probably won't be back till 12:30 CEST.
Klaus
115,123d114 < * < * rs6000.c calls abort() if this is "GNU Pascal" :-) < * < * I have modified rs6000.c. Since "Pascal" is a person's name < * like "Ada" it has the right to be written in the same manner. :-) < * - PG < * < * Sigh, I don't want to change rs6000.c; I will inform Kenner to change < * it in the next release. 125,127d115 < #ifdef _IBMR2 < char *language_string = "GNU PASCAL"; < #else 129d116 < #endif /* Sigh */
Hi all,
Apparently I'm on the list now (right, administrator?)...
Klaus suggested:
So here you go, abort! Who messed around with the language_string recently? This should be rather trivial to fix for Peter. The actual bug is in p/parse.c and is even documented. Just take the language_string hack for _IBMR2 out and your compiler should work. The "bug" is around line 360 in p/parse.c. Of course, to fix this, we need to change p/parse.y, being the source for parse.c. Nick, do you have bison installed on your machine? If not, you have to change p/parse.c by hand for a quick fix, and don't apply the p/parse.y patch below.
Yes I have bison. I changed p/parse.y the way you suggested (I can't use `patch', on aix `patch' doesn't seems to behave the way it should. BTW, the gpc patches that needed to be applied in GPC: configure didn't apply them because of this problem. This in turn caused my first linking problem that Peter related to a VPATH problem, but which was not. I was eventually able to apply the patches by moving the files to a linux machine, using `patch' and then moving back the fixed files to the aix machine. So in future releases of gpc this patch problem with aix should be fixed -- but this all aside and between brackets :-) To continue: I resumed gmake and now the rts part of p has been built! I got a few errors which did not cause s stop of gmake, I'm not sure if they are a problem (should I worry about them?):
---begin--- gmake[1]: Entering directory `/backup/gnu/gcc-2.8.1/p/rts' ../../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 gpc.pas rts-base.p:38: #error Bit endianness is not defined! rts-base.p:43: #error Byte endianness is not defined! rts-base.p:48: #error Word endianness is not defined! gpc1: gpc exited with status 1 gpc.pas:331: warning: no previous prototype for `__init_Gpc' ---end---
Anyway, at this very moment gmake has finished the build and I will now make the stage2 compiler, install and run some tests (fingers crossed...). I'll keep you all informed on how this evolves.
Oh yes, another thing: just checked and I noticed that the _IBMR2 faulty hack in p/parse.y was already present in version gpc-971001.
Greetz and already many thanks to Peter and Klaus,
Nick
Nick Cremelie wrote:
Hi all,
Apparently I'm on the list now (right, administrator?)...
If you receive this mail twice, then you're on.
Klaus suggested:
So here you go, abort! Who messed around with the language_string recently? This should be rather trivial to fix for Peter. The actual bug is in p/parse.c and is even documented. Just take the language_string hack for _IBMR2 out and your compiler should work. The "bug" is around line 360 in p/parse.c. Of course, to fix this, we need to change p/parse.y, being the source for parse.c. Nick, do you have bison installed on your machine? If not, you have to change p/parse.c by hand for a quick fix, and don't apply the p/parse.y patch below.
Yes I have bison. I changed p/parse.y the way you suggested (I can't use `patch', on aix `patch' doesn't seems to behave the way it should. BTW, the gpc patches that needed to be applied in GPC: configure didn't apply them because of this problem. This in turn caused my first linking problem that Peter related to a VPATH problem, but which was not. I was eventually able to apply the patches by moving the files to a linux machine, using `patch' and then moving back the fixed files to the aix machine. So in future releases of gpc this patch problem with aix should be fixed -- but this all aside and between brackets :-)
Well, it is possible that it was due to my crappy patch. I should have passed -c to diff, and even AIX patch should understand the patch then. Another option is to install GNU patch, which is (at least the current, fairly stable version) heaps better than any proprietary patch program.
Anyway, I've just looked at the gpc diffs, and they seem to be in unified diff format, which isn't uderstood by all patch programs. Maybe Peter should change this back to normal context diffs. They're larger but more portable.
To continue: I resumed gmake and now the rts part of p has been built! I got a few errors which did not cause s stop of gmake, I'm not sure if they are a problem (should I worry about them?):
I would worry about them. But it's possible that they go away after you installed gpc and re-do the gpc compilation. You can check if something is wrong with the gpc driver program if you start it with option -v for the program issuing the errors. There should be either a "-D__BYTES_BIG_ENDIAN__" or a "-D__BYTES_LITTLE_ENDIAN__" in the command line for the preprocessor. Similarly for BITS and WORD.
I wouldn't trust gpc until there are no #error lines left. Part of the problem seems to be that the automake feature doesn't pass the error code of a failed sub-compile command back to the calling make program.
Peter: can you put this on the automake todo list?
[...]
Anyway, at this very moment gmake has finished the build and I will now make the stage2 compiler, install and run some tests (fingers crossed...). I'll keep you all informed on how this evolves.
Well, there is no real stage2 for gpc, as it's written in C. The code *generated* by gcc (in this case gpc) shouldn't change at all for any stage. The code of gcc of course changes, as it's built with different compilers and options.
There are some build process problems with the gpc rts currently, which can be resolved by ignoring the build errors in the first build, and installing the compiler anyway (which may not be fully functional in this state). Then do a "make clean" on the gcc source tree and rebuild gpc. There should be no error messages in the second build (apart from some "error code xx ignored" messages from make).
I should start testing gpc a bit more thoroughly, as we're going to use some version of it in the upcoming ACM South West European Programming Contest this year. It's just that I'm short on time and drive space, as our uni "only" gives us 24 megs space. Doing work in some /tmp dir isn't much fun.
Klaus
Hmmm...this thread is growing like a loooooong story... :-)
To continue: I resumed gmake and now the rts part of p has been built! I got a few errors which did not cause s stop of gmake, I'm not sure if they are a problem (should I worry about them?):
I would worry about them. But it's possible that they go away after you installed gpc and re-do the gpc compilation. You can check if something is wrong with the gpc driver program if you start it with option -v for the program issuing the errors. There should be either a "-D__BYTES_BIG_ENDIAN__" or a "-D__BYTES_LITTLE_ENDIAN__" in the command line for the preprocessor. Similarly for BITS and WORD.
These errors mysteriously disappeared in the second pass... So I did the install and starting testing with the programs in the directory p/test/misc
Fibonacci works fine (wow, finally gpc compiles something for me...)
...but: txtfile and binfile both crash with:
?GPC runtime error: (gpc-rts) _p_initfdr() has not been called for file (#701)
Now what's that???????
I suppose it has something to do with the "bind" functionality in gpc for binding an external file to a variable???
Nick
-
Klaus Espenlaub -
Nick Cremelie