I'm having some issues in getting gpc compiled following the directions at http://www.gnu-pascal.de/gpc_42.html#SEC42
Here is what I have done and the results I'm getting.
1st attempt used gcc-core-3.2.1.tar.gz & gpc-20021128.tar.gz
followed the directions from the above page and everything compiled as expeced. I read the README in the test directory and it indicated to run make in the test dir or make check in the p dir. I did the make check in the p dir. During the test gpc would get Internal compiler errors on every test which meant that all tests failed. NOTE: The this was done prior to runing make install.
Here is one of the error messages I got just so you know the exact output.
TEST aturbo3test.pas: /home/src/gcc-3.2.1/gcc/p/test/../units/system.pas: In function `Memavail': /home/src/gcc-3.2.1/gcc/p/test/../units/system.pas:827: Internal compiler error in gen_tagged_type_instantiation_die, at dwarf2out.c:11247 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu-pascal.de/todo.html for instructions. gpc1: /home/src/gpc-build/gcc/xgpc exited with status 1 gpc1: /home/src/gpc-build/gcc/xgpc exited with status 1 failed
After this failed I decided to install the full gpc sources that my distribution uses ( gentoo by the way ). the source used is gpc-3.2.1 with some patches applied: gcc-3.2.1-branch-update-20021208.patch gcc-3.2.1-bug-url.patch gcc32-ada-make.patch gcc32-shared-pthread.patch gcc32-testsuite.patch gcc32-tls-reload-fix.patch (NOTE: I can supply these to any one that wants them. most of them are really small except the branch-update patch wich is about 1M when compressed with bzip2 )
When I ran configure on this one I had one gpc patch fail to apply. It was the bug url patch as the above gentoo patch had changed the url to a gentoo url verses the gnu url so I fixed the gpc patch to reflect the change and got a clean gpc patch.
Now on to running make.
When Make ran I got this error which I have been unable to track down as from what I can see it looks OK.
In file included from /var/tmp/portage/gcc-3.2.1-r6/work/gcc-3.2.1/gcc/p/gpc-common.c:27: /var/tmp/portage/gcc-3.2.1-r6/work/gcc-3.2.1/gcc/p/gpc.h:667: conflicting types for `global_trees' /var/tmp/portage/gcc-3.2.1-r6/work/gcc-3.2.1/gcc/tree.h:1956: previous declaration of `global_trees' make[1]: *** [p/gpc-common.o] Error 1
Line 667 in gpc.h extern tree size_type_node;
Line 1956 in tree.h extern tree global_trees[TI_MAX];
tree.h line 1998 #define size_type_node global_trees[TI_SIZE_TYPE]
TI_MAX & TI_SIZE_TYPE are part of a enum where TI_MAX is the last item and TI_SIZE_TYPE is last part of the enum. I've greped the sources for gcc and gpc and can't seem to find where tree is defined to see what is going on.
If anyone could point me where to look to solve this I would appreciate it.
In the mean time I'm going to give another go at doing it from the clean gcc sources. but this time I'm going to get the full sources.
Thanks Richard
Richard D. Jackson wrote:
I'm having some issues in getting gpc compiled following the directions at http://www.gnu-pascal.de/gpc_42.html#SEC42
Here is what I have done and the results I'm getting.
1st attempt used gcc-core-3.2.1.tar.gz & gpc-20021128.tar.gz
The gcc-3 based GPC does not yet work with "dwarf2" debug info (which is the default on many platforms). Therefore you'll have to add `-g0' (no debug info at all) or `-gstabs' (which works on many systems). When testing, add it in EXTRA_TEST_PFLAGS on the make command line.
When I ran configure on this one I had one gpc patch fail to apply. It was the bug url patch as the above gentoo patch had changed the url to a gentoo url verses the gnu url so I fixed the gpc patch to reflect the change and got a clean gpc patch.
The same was reported with a GCC for Mac OS X patched by Apple.
I think it should work directly if we change our diff to:
*** gcc/system.h.orig Fri Oct 25 15:11:09 2002 --- gcc/system.h Mon Nov 25 15:30:37 2002 *************** *** 30,31 **** --- 30,36 ----
+ #ifdef GPC + #undef GCCBUGURL + #define GCCBUGURL "URL:http://www.gnu-pascal.de/todo.html" + #endif + /* We must include stdarg.h/varargs.h before stdio.h. */
Now on to running make.
When Make ran I got this error which I have been unable to track down as from what I can see it looks OK.
In file included from /var/tmp/portage/gcc-3.2.1-r6/work/gcc-3.2.1/gcc/p/gpc-common.c:27: /var/tmp/portage/gcc-3.2.1-r6/work/gcc-3.2.1/gcc/p/gpc.h:667: conflicting types for `global_trees' /var/tmp/portage/gcc-3.2.1-r6/work/gcc-3.2.1/gcc/tree.h:1956: previous declaration of `global_trees' make[1]: *** [p/gpc-common.o] Error 1
We're aware of this problem (when using post-3.2.1 GCC's). It will be fixed in the next GPC alpha. If you want to try it now, just remove the following two lines:
gpc.h: extern tree size_type_node;
gpc-decl.c: tree size_type_node;
Frank
On Wed, 2003-01-22 at 09:06, Frank Heckenbach wrote:
Richard D. Jackson wrote:
<snip>
The gcc-3 based GPC does not yet work with "dwarf2" debug info (which is the default on many platforms). Therefore you'll have to add `-g0' (no debug info at all) or `-gstabs' (which works on many systems). When testing, add it in EXTRA_TEST_PFLAGS on the make command line.
That did the trick. Now all tests pass with the exception of the 5 that are skiped.
<snip>
The same was reported with a GCC for Mac OS X patched by Apple.
I think it should work directly if we change our diff to:
*** gcc/system.h.orig Fri Oct 25 15:11:09 2002 --- gcc/system.h Mon Nov 25 15:30:37 2002
*** 30,31 **** --- 30,36 ----
- #ifdef GPC
- #undef GCCBUGURL
- #define GCCBUGURL "URL:http://www.gnu-pascal.de/todo.html"
- #endif
- /* We must include stdarg.h/varargs.h before stdio.h. */
That did the trick and is much cleaner that what I did.
<snip>
We're aware of this problem (when using post-3.2.1 GCC's). It will be fixed in the next GPC alpha. If you want to try it now, just remove the following two lines:
gpc.h: extern tree size_type_node;
gpc-decl.c: tree size_type_node;
Ok commented out the above two lines. Now I'm getting a whole bunch of undefined reference errors. So for now I'm going to stick with the vanilla gcc sources ( which works ). For your referance though below I've listed some of the undefined reference errors you will note that the errors are in both gpc and gcc.
gcc/p/gpc-common.c:774: undefined reference to `tree_code_type' gcc/p/gpc-common.c:785: undefined reference to `tree_code_type' gcc/p/gpc-common.c:790: undefined reference to `tree_code_type' gcc/p/gpc-common.c:808: undefined reference to `tree_code_type' gcc/p/gpc-common.c:818: undefined reference to `tree_code_type' gcc/p/gpc-common.c:845: more undefined references to `tree_code_type' gcc/p/gpc-typeck.c:2852: undefined reference to `tree_code_length' gcc/p/gpc-typeck.c:2947: undefined reference to `tree_code_type' gcc/p/gpc-typeck.c:2955: undefined reference to `tree_code_length' gcc/p/gpc-typeck.c:4329: undefined reference to `tree_code_type' gcc/p/gpc-typeck.c:4976: undefined reference to `tree_code_type' gcc/p/gpc-typeck.c:7447: undefined reference to `tree_code_type' gcc/p/gpc-typeck.c:7448: undefined reference to `tree_code_type' gcc/fold-const.c:3475: undefined reference to `tree_code_length' gcc/fold-const.c:4083: undefined reference to `tree_code_type' gcc/fold-const.c:4392: undefined reference to `tree_code_type' gcc/fold-const.c:4529: undefined reference to `tree_code_type' gcc/fold-const.c:4549: undefined reference to `tree_code_type' gcc/fold-const.c:4809: undefined reference to `tree_code_type' gcc/fold-const.c:5017: more undefined references to `tree_code_type' gcc/tree.c:273: undefined reference to `tree_code_length' gcc/tree.c:259: undefined reference to `tree_code_length' gcc/tree.c:279: undefined reference to `tree_code_length' gcc/tree.c:302: undefined reference to `tree_code_type' gcc/tree.c:471: undefined reference to `tree_code_type' gcc/tree.c:1711: undefined reference to `tree_code_type' gcc/tree.c:1827: undefined reference to `tree_code_type' gcc/tree.c:1876: undefined reference to `tree_code_type' gcc/tree.c:1931: undefined reference to `tree_code_length'
Richard D. Jackson wrote:
Ok commented out the above two lines. Now I'm getting a whole bunch of undefined reference errors. So for now I'm going to stick with the vanilla gcc sources ( which works ). For your referance though below I've listed some of the undefined reference errors you will note that the errors are in both gpc and gcc.
gcc/p/gpc-common.c:845: more undefined references to `tree_code_type' gcc/p/gpc-typeck.c:2852: undefined reference to `tree_code_length'
Apparently they've changed more things. If someone can provide me with the respective changes, I'll integrate them. Otherwise I'll wait until they appear in the next GCC release.
Frank
On Wed, 2003-01-22 at 18:46, Frank Heckenbach wrote:
Richard D. Jackson wrote:
Ok commented out the above two lines. Now I'm getting a whole bunch of undefined reference errors. So for now I'm going to stick with the vanilla gcc sources ( which works ). For your referance though below I've listed some of the undefined reference errors you will note that the errors are in both gpc and gcc.
gcc/p/gpc-common.c:845: more undefined references to `tree_code_type' gcc/p/gpc-typeck.c:2852: undefined reference to `tree_code_length'
Apparently they've changed more things. If someone can provide me with the respective changes, I'll integrate them. Otherwise I'll wait until they appear in the next GCC release.
Frank
I can supply you with the branch update patch that is used in Gentoo. Along with the other patches that are applied to the sources if you want them. Just let me know where to send them. I would like to set this done as from what I understand the branch update fixes some CPU optimization code.
Richard
Richard D. Jackson wrote:
gcc/p/gpc-common.c:845: more undefined references to `tree_code_type' gcc/p/gpc-typeck.c:2852: undefined reference to `tree_code_length'
Apparently they've changed more things. If someone can provide me with the respective changes, I'll integrate them. Otherwise I'll wait until they appear in the next GCC release.
Frank
I can supply you with the branch update patch that is used in Gentoo. Along with the other patches that are applied to the sources if you want them. Just let me know where to send them. I would like to set this done as from what I understand the branch update fixes some CPU optimization code.
Actually, I wouldn't like to work through a bunch of GCC diffs. If you can find the relevant changes or even better, a suggested diff to GPC, just send it to me.
Frank
On Thu, 2003-01-23 at 08:40, Frank Heckenbach wrote:
Richard D. Jackson wrote:
<snip>
Actually, I wouldn't like to work through a bunch of GCC diffs. If you can find the relevant changes or even better, a suggested diff to GPC, just send it to me.
Frank
When I first read this I thought OH man I don't even know where to start but what the heck I'll take a look :) so fired up grep and and went to work. And here is what I found:
1) The declaration for tree_code_type, tree_code_length, and tree_code_name have been moved out of core and moved to the language front-ends ( according to the ChangeLog )
More precisly they have been moved from tree.c to: com.c for Fortran??? what ever the f directory is for that is. cp-lang.c for C++ misc.c for ada lang.c for java objc-lang.c for Objective C c-lang.c for C
On top of that the types have changed as well. tree_code_type changed from char to const char tree_code_length changed from int to const unsigned char tree_code_name changed from const char * to const char *const
2) So lets see what happens when I move them into lang.c on the pascal side. On a side note moving this to the language front end eleminated the language specific tree code as well from the other front ends. other words the C front end no longer has a c_tree_code_type it just has tree_code_type the same goes for the other vars as well.
I did not try to replace the pascal_tree_code_????? I just added in the tree_code_???? vars and added the langhooks-def.h header as it was needed for the def's.
Got it to compile but now it segfaults when trying to compile rtsc.pas.
I will look into why it is doing that later tonight. Or I should say I will try as this compiler stuff is way over my head.
Richard
Richard D. Jackson wrote:
On Thu, 2003-01-23 at 08:40, Frank Heckenbach wrote:
Richard D. Jackson wrote:
<snip> > Actually, I wouldn't like to work through a bunch of GCC diffs. If > you can find the relevant changes or even better, a suggested diff > to GPC, just send it to me. > > Frank
When I first read this I thought OH man I don't even know where to start but what the heck I'll take a look :) so fired up grep and and went to work.
Well, that's how I usually start when I dive into a new area of the compiler ... ;-)
And here is what I found:
- The declaration for tree_code_type, tree_code_length, and
tree_code_name have been moved out of core and moved to the language front-ends ( according to the ChangeLog )
More precisly they have been moved from tree.c to: com.c for Fortran??? what ever the f directory is for that is. cp-lang.c for C++ misc.c for ada lang.c for java objc-lang.c for Objective C c-lang.c for C
On top of that the types have changed as well. tree_code_type changed from char to const char tree_code_length changed from int to const unsigned char tree_code_name changed from const char * to const char *const
- So lets see what happens when I move them into lang.c on the pascal
side. On a side note moving this to the language front end eleminated the language specific tree code as well from the other front ends. other words the C front end no longer has a c_tree_code_type it just has tree_code_type the same goes for the other vars as well.
I did not try to replace the pascal_tree_code_????? I just added in the tree_code_???? vars and added the langhooks-def.h header as it was needed for the def's.
Got it to compile but now it segfaults when trying to compile rtsc.pas.
I will look into why it is doing that later tonight. Or I should say I will try as this compiler stuff is way over my head.
I'm not sure exactly, but have you made sure that the common tree codes are put in tree_code_* the way they should be (up to now, GPC added only the Pascal specific ones, while the common ones were supplied by the backend)? More generally, that the variables are initialized the same way they are in the other languages ...
If that doesn't help, I guess it's time for gdb ... ;-)
Frank
On Sat, 2003-01-25 at 18:11, Frank Heckenbach wrote:
Richard D. Jackson wrote:
On Thu, 2003-01-23 at 08:40, Frank Heckenbach wrote:
Richard D. Jackson wrote:
<snip>
<snip>
When I first read this I thought OH man I don't even know where to start but what the heck I'll take a look :) so fired up grep and and went to work.
Well, that's how I usually start when I dive into a new area of the compiler ... ;-)
You just have to love grep one of the best tools ever created IMHO.
<snip>
I'm not sure exactly, but have you made sure that the common tree codes are put in tree_code_* the way they should be (up to now, GPC added only the Pascal specific ones, while the common ones were supplied by the backend)? More generally, that the variables are initialized the same way they are in the other languages ...
If that doesn't help, I guess it's time for gdb ... ;-)
Frank
Yes I put the common tree codes under tree_code_* in the lang.c file of the gpc front end. What I think may be the problem is that the type changed on tree_code_length from int to const unsigned char. The other two where just changed to a const which I don't think would cause a segfault but then again it may if the gpc front end is trying to change them.
Right now I don't have allot of time so I'm trying to decide what is the best use of the time I do have. There are a few things I would like to do to contribute to the gpc effort and I'm not sure that digging into the compiler code would be the best use of the time I have. Maybe later when I have more time I will do that as I find it interesting and would be a good learning experance.
Right now I'm floating these ideas on things I can do : 1) work on the documentation as there are quite a few holes in it. 2) write some more units ( file streams and a collection class are two things I would like to have for use in gpc so that would be what I would start with ) 3) write some of the missing utilites ( A automake like tool for gpc, a source code beutifier, a documentation tool )
All three of these would also have the side benifit of helping me to learn pascal. And number three will need number two. So what I may end up doing is starting with 1 by working on the areas where I have some interest then move to 2 and 3.
But I can't really start on any of them until I finish reading the documentation that is availible and get a better feel of what is needed. Like for one there is alot of things in the RTS system that is not documented ( well what I should say is that it is not documented in a way that a newbe would find easy to digest that is ).
So for the time being I'm going to spend my time reading and move from there by floating some documentation updates or changes to the list. Once I get a little more cofortable with pascal then I will tackel 2 and 3.
Richard
On 26 Jan 2003 at 22:39, Richard D. Jackson wrote:
[....]
Right now I'm floating these ideas on things I can do :
- work on the documentation as there are quite a few holes in it.
- write some more units ( file streams and a collection class are two
things I would like to have for use in gpc so that would be what I would start with )
The BP-compatible objects unit (see /contrib/chief/ on the GPC web site) has stream and collection objects.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
Richard D. Jackson wrote:
Well, that's how I usually start when I dive into a new area of the compiler ... ;-)
You just have to love grep one of the best tools ever created IMHO.
Sure, and it's one of the programs I use most (next to ls maybe :-).
<snip> > I'm not sure exactly, but have you made sure that the common tree > codes are put in tree_code_* the way they should be (up to now, GPC > added only the Pascal specific ones, while the common ones were > supplied by the backend)? More generally, that the variables are > initialized the same way they are in the other languages ... > > If that doesn't help, I guess it's time for gdb ... ;-)
Yes I put the common tree codes under tree_code_* in the lang.c file of the gpc front end. What I think may be the problem is that the type changed on tree_code_length from int to const unsigned char. The other two where just changed to a const which I don't think would cause a segfault but then again it may if the gpc front end is trying to change them.
It should not change them (apart from the initialization in lang.c which I suppose is dropped now).
I don't see how the int->char change should be a problem, either, but I don't know exactly ...
Right now I don't have allot of time so I'm trying to decide what is the best use of the time I do have. There are a few things I would like to do to contribute to the gpc effort and I'm not sure that digging into the compiler code would be the best use of the time I have.
OK, I guess then Waldek or I will deal with the issue when we get to it (I probably won't try it until the release of a new GCC version).
Maybe later when I have more time I will do that as I find it interesting and would be a good learning experance.
Right now I'm floating these ideas on things I can do :
- work on the documentation as there are quite a few holes in it.
Indeed (in some areas the holes are bigger than the rest ;-).
- write some of the missing utilites ( A automake like tool for gpc,
I'm working on it (this is, when I'm not busy with GPC bugs etc.). Much of it is finished, but a few substantial problems are left. Probably not a good starter project since there would be some learning of the internals of the utility first ...
a source code beutifier,
Eike Lange and Thorsten Hindermann wrote a tool (pindent) some time ago, but I don't know if it has been updated to conform with the GPC Coding Standards.
a documentation tool )
(See my other mail.)
But I can't really start on any of them until I finish reading the documentation that is availible and get a better feel of what is needed. Like for one there is alot of things in the RTS system that is not documented ( well what I should say is that it is not documented in a way that a newbe would find easy to digest that is ).
I know -- the only way many things are documented are in the interface of the GPC unit (if you don't want to go into the implementation which is often quite low-level).
So for the time being I'm going to spend my time reading and move from there by floating some documentation updates or changes to the list.
BTW, there is a separate list for documentation issues gpc-doc@gnu.de since probably not all readers of this list are interested in those patches.
Frank
On Mon, 2003-01-27 at 20:05, Frank Heckenbach wrote:
Richard D. Jackson wrote:
<snip>
a source code beutifier,
Eike Lange and Thorsten Hindermann wrote a tool (pindent) some time ago, but I don't know if it has been updated to conform with the GPC Coding Standards.
googled pindent and the only link I found was to: http://mond.dida.physik.uni-essen.de/~pindent/ which does not seem to exist anymore. The other pindent found was sun one and a python tool of the same name.
a documentation tool )
(See my other mail.)
<snip>
So for the time being I'm going to spend my time reading and move from there by floating some documentation updates or changes to the list.
BTW, there is a separate list for documentation issues gpc-doc@gnu.de since probably not all readers of this list are interested in those patches.
Didn't know that I will subscibe to it today. And move documentation related questions/ideas over to it.
Richard
Hi!
On Mon, Jan 27, 2003 at 11:15:24PM -0600, Richard D. Jackson wrote:
On Mon, 2003-01-27 at 20:05, Frank Heckenbach wrote:
Eike Lange and Thorsten Hindermann wrote a tool (pindent) some time ago, but I don't know if it has been updated to conform with the GPC Coding Standards.
googled pindent and the only link I found was to: http://mond.dida.physik.uni-essen.de/~pindent/ which does not seem to exist anymore. The other pindent found was sun one and a python tool of the same name.
It isn't finished and the existing code is not usable anymore. If you like, I could send you a copy of the very alpha source.
Eike
-
Eike Lange -
Frank Heckenbach -
Prof A Olowofoyeku (The African Chief) -
Richard D. Jackson