Hi,
I've uploaded a new alpha version.
Most importantly, thanks to Waldek stabs debugging should now work (at least under Linux, haven't tested on other platforms yet). Also, coff debugging (DJGPP) might work ...
Furthermore, the license of the documentation has changed to the GNU Free Documentation License (the counterpart of the GPL for manuals etc.). Thanks to Eike for doing the formalities.
Besides, some changes according to recent bug reports and more cleanups have been made. The two makefiles (Make-lang.in and Makefile.in) have been merged (also for gcc-3 integration) -- I don't know if anyone cares, but perhaps those who build GPC in special ways ...
Frank
Frank Heckenbach wrote:
Most importantly, thanks to Waldek stabs debugging should now work (at least under Linux, haven't tested on other platforms yet).
PS: Forgot to mention, since stabs is not the default with gcc-3, you must give `-gstabs' instead of simply `-g' to use it.
In particular, if you're going to send test results, add `EXTRA_TEST_PFLAGS=-g0' (at least under Linux).
Frank
There is a problem under Windows (Mingw) when using gcc-3.x sources. This problem came up under the last alpha as well. I am using gcc-3.2.1 sources (but it was also there under gcc-3.1.1).
This is the scenario:
1. Build GPC with these CFLAGS: "-O2 -g -march=i486 -mcpu=i686 -fomit-frame-pointer" (the real culprit seems to be "-fomit-frame-pointer" - but it also needs the cpu switches - if you remove either the cpu switches or "-fomit-frame-pointer", then the problem doesn't occur). The "-g" switch is not significant - the problem is the same with or without it.
2. compile the following program (whether with "-g0" or "-g" or "-gstabs" or without any debugging info): program bug2; var f : text; begin assign (f, 'foo.txt'); rewrite (f); writeln (f, 'OK'); close (f); end.
3. run the program:
4. You get an almight crash, and this report from gdb:
C:\usr\test>gdb bug2.exe GNU gdb 5.2.1 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "mingw32"... (gdb) run Starting program: C:\usr\test/bug2.exe
Program received signal SIGSEGV, Segmentation fault. $00410f19 in _p_assign (T=@$0, Name=@$0) at d:/src/gcc-3.2.1/gcc/p/rts/files.pas:148 148 B.Name := Name; Current language: auto; currently pascal
5. By the same token, many programs in the test suite result in the same almighty crash, so the test suite is unrunnable. Now the "-fomit-frame-pointer" switch is unimportant, and I can easily dispense with it. But it seems that using it has unearthed a problem somewhere.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
Prof A Olowofoyeku (The African Chief) wrote:
There is a problem under Windows (Mingw) when using gcc-3.x sources. This problem came up under the last alpha as well. I am using gcc-3.2.1 sources (but it was also there under gcc-3.1.1).
Sorry, I can't reproduce it under Linux. Do you use any GCC patches (except GPC's one, of course)? Maybe I'll notice something if you send me the assembler files of a correct and an incorrect compilation.
Frank
Frank Heckenbach writes:
Besides, some changes according to recent bug reports and more cleanups have been made. The two makefiles (Make-lang.in and Makefile.in) have been merged (also for gcc-3 integration) -- I don't know if anyone cares, but perhaps those who build GPC in special ways ...
who should build gpc in special ways?
Find attached a patch to build gpc with current gcc-3_2-branch.
--- src/gcc/p/gpc.h~ 2002-11-06 06:51:56.000000000 +0100 +++ src/gcc/p/gpc.h 2002-12-02 19:13:32.000000000 +0100 @@ -749,7 +749,9 @@ extern tree boolean_true_node; extern tree ptrsize_unsigned_type_node; extern tree ptrsize_integer_type_node; +#if (__GNUC__ <= 3) && (__GNUC_MINOR__ <= 2) && (__GNUC_PATCHLEVEL__ <= 1) extern tree size_type_node; +#endif extern tree packed_array_unsigned_long_type_node; extern tree packed_array_unsigned_short_type_node; extern tree const_string_type_node;
Matthias Klose wrote:
Frank Heckenbach writes:
Besides, some changes according to recent bug reports and more cleanups have been made. The two makefiles (Make-lang.in and Makefile.in) have been merged (also for gcc-3 integration) -- I don't know if anyone cares, but perhaps those who build GPC in special ways ...
who should build gpc in special ways?
Apparently quite a few, telling from some messages I've seen here ... ;-)
Find attached a patch to build gpc with current gcc-3_2-branch.
--- src/gcc/p/gpc.h~ 2002-11-06 06:51:56.000000000 +0100 +++ src/gcc/p/gpc.h 2002-12-02 19:13:32.000000000 +0100 @@ -749,7 +749,9 @@ extern tree boolean_true_node; extern tree ptrsize_unsigned_type_node; extern tree ptrsize_integer_type_node; +#if (__GNUC__ <= 3) && (__GNUC_MINOR__ <= 2) && (__GNUC_PATCHLEVEL__ <= 1) extern tree size_type_node; +#endif extern tree packed_array_unsigned_long_type_node; extern tree packed_array_unsigned_short_type_node; extern tree const_string_type_node;
Not quite. __GNUC__ etc. checks the version of the build compiler, but the problem seems to be related to the backend (source) used. (Apart from that, the condition would be wrong, since it would fail for, e.g., gcc-2.95.x where __GNUC_MINOR__ is 95.)
Apparently the problem stems from some difference of the current branch an the gcc-3.2.1 release (I've just tested the latter on a Debian GNU/Linux system, IA32, without any problems).
I suppose they've changed something about sizetype. I'd have to see the changes exactly to tell if it's enough to remove the declaration, or if more changes are needed. (Maybe you can send me the relevant changes, or a diff against 3.2.1 by private mail ...)
It might require another version check in config-lang.in.
Frank
Frank Heckenbach a écrit:
I've uploaded a new alpha version.
Good news !!! Since gpc-3.2.1 for djgpp has been released this week, I have tried to compile this alpha (20021128) with it on djgpp. It works seamlessly, no patches needed beyond the ordinary djgpp and gpc patches. Running the test suite with -g0 there is only one real error on fjf341b
------------------------------------------------------------ TEST fjf165a.pas: SKIPPED: German locale not installed TEST fjf341b.pas: c:/djgpp/b/gnu/gcc-3.21/gcc/p/test/fjf341b.pas:5: tree c heck: expected integer_cst, have plus_expr in tree_int_cst_sgn, at tree.c:3522 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu-pascal.de/todo.html for instructions. failed TEST longr2.pas: SKIPPED: no LongReal math routines available TEST pipetes2.pas: The process terminated with status 0.
# of GPC tests 2856 # of GPC tests passed 2852 # of GPC tests skipped 2 # of GPC tests failed 2 -----------------------------------------------------------
I have uploaded the resulting gpc321b.zip in the usual directory
http://gnu-pascal.de/contrib/maurice/
For those who might want to check I have also uploaded in this directory the modified gcc321s2.zip I have used. I have made exactly what is described in the readme.gpc file in the root directory of this zip.
I do not know what was wrong with gc-3.1.1 (compiling this alpha with it still crashed), but we can forget about it now.
Maurice
Maurice Lombardi wrote:
Frank Heckenbach a écrit:
I've uploaded a new alpha version.
Good news !!! Since gpc-3.2.1 for djgpp has been released this week, I have tried to compile this alpha (20021128) with it on djgpp. It works seamlessly, no patches needed beyond the ordinary djgpp and gpc patches. Running the test suite with -g0 there is only one real error on fjf341b
... snip ...
I have uploaded the resulting gpc321b.zip in the usual directory
http://gnu-pascal.de/contrib/maurice/
For those who might want to check I have also uploaded in this directory the modified gcc321s2.zip I have used. I have made exactly what is described in the readme.gpc file in the root directory of this zip.
Great. Now if gcc will only settle down :-) How far is the whole system now from full inclusion in gcc and simtel distribution?
CBFalconer writes:
Great. Now if gcc will only settle down :-) How far is the whole system now from full inclusion in gcc and simtel distribution?
major new chunks of code are added only on the HEAD branch, if it's in stage 1 of the release schedule (http://gcc.gnu.org/develop.html).
So, if you want to do some work on this, you may want to check the bib-3.4-branch (basic improvements branch, which will become HEAD after the gcc-3_3-branch forks) and try to build gpc against this version. Stage 1 usually is a two-month period, the one for 3.4 probably beginning in late December. If you miss this, gpc won't be in gcc-3.4 and has to wait for gcc-3.5.
In the past, there has been lack of interest, lack of resources and IIRC some disappointment how or if at all patches are getting merged into gcc.
So if this merge will ever happen, someone has to bite the bullet to work on the unstable gcc ...
Matthias Klose wrote:
CBFalconer writes:
Great. Now if gcc will only settle down :-)
I don't know if GCC will ever settle down. They'll keep making advances and new versions, and that's a good thing, isn't it? :-)
How far is the whole system now from full inclusion in gcc and simtel distribution?
major new chunks of code are added only on the HEAD branch, if it's in stage 1 of the release schedule (http://gcc.gnu.org/develop.html).
[...]
In the past, there has been lack of interest, lack of resources and IIRC some disappointment how or if at all patches are getting merged into gcc.
So if this merge will ever happen, someone has to bite the bullet to work on the unstable gcc ...
Let's not forget that there are some issues to be solved before this should happen. The following are only the major points that come to my mind right now. I may be missing some, and there are some smaller points as well:
- First of all, get the gcc-3 port stable. (FTR, within a few days before the last alpha, I found 4 memory management related bugs. I fixed them before the release, but on the basis of any reasonable statistics one should expect to find some more in the nearer future.)
- Fix the debug info. (Waldek is working on that ...)
- Clean up the backend patches. Some parts of them are related to the debug info problems, and may be kludges, some more are also debatable, others need some cleanups. I could well understand the GCC developers rejecting such patches, and I don't think it would be a good idea to put bad or dubious patches in GCC now and fix them later.
- Remove automake. This is a necessity for getting the compiler driver in synch (or even close to) that of the C compiler (and all other languages, AFAIK). Of course, this means that the replacement (gp) has to be finished before. If we want to do this well, this means at least going through several betas and probably a number of changes until it is satisfactory for all needs.
- Dropping the gcc-2 support. Of course, the GCC developers won't want to put in code for older GCC versions (even if conditional) in the current code. But this means, either keep two GPC source trees, one with and one without the gcc-2 conditionals (and that means, someone will have to maintain them, since I certainly won't do that; and I can tell you from experience with smaller "divergences" that it will be a boring, error-prone and generally distasteful job ;-), or to wait until gcc-2 support can be removed from GPC at all in good conscience (i.e., in a regular release cycle, like getting gcc-3 support stable in our tests, ask everyone to try it, deprecate gcc-2 support, have a major GPC release with gcc-3 support preferred and gcc-2 support deprecated, and if then no major problems appear, drop gcc-2 support).
Of course, if you really want to, you can "bite the bullet" and try integration right now. But I'm quite sure it will be much more work in total than is doing it in the proper order, and it will be technically dubious solutions (both from the GCC and the GPC viewpoint, in different areas).
OTOH, I don't see any big advantage in hurrying it. It may be easier for distribution makers (so I see your POV, Matthias), but then again, I suppose you have your build scripts in place for the current situation, and changing them to a cleaner (in this regard) style now or later doesn't make a big difference. I don't know about the "simtel distribution" Chuck mentioned -- it's no problem today to make distributions in any form (in source, if wanted, including the GCC sources, already patched possibly; sure, the archive would be a little bigger, some 15 MB instead of 2 MB, but from my impression, most Internet users won't even notice the diffrence today ;-).
Actually I wonder where this "panic" about gcc integration comes from. Since some time, I keep hearing these requests every other week. GPC has been developed for years without such an integration, and I doubt it would have been essentially better if it was integrated -- maybe even worse; currently, when there are severe backend problems (such as the `goto' bug in 2.95 on Solaris/Sparc), there is the recourse to try another GCC version; if it was integrated and tied to one GCC version, we'd depend on that version ...
Finally, if all that doesn't convince you, I'll put it in a more selfish way. The main reason why I do GPC development is that I also use GPC myself, and it's both useful and interesting to improve the tools I'm using. GCC integration doesn't provide any direct advantage to my work using GPC, so I don't feel like putting any unnecessary work in it (which would be caused by hurrying it).
So, everyone who wants to actually help the GCC integration, just pick your job from the list above (or another one I may have missed). So far only Waldek (with the "port" for gcc-3) and Eike (with the manual license change to FDL, which was another requirement) have done so (and I have done some things WRT the Makefiles and in the code which I found also useful independently of the GCC integration ;-).
Frank
Matthias Klose wrote:
CBFalconer writes:
Great. Now if gcc will only settle down :-)
I don't know if GCC will ever settle down. The developers will keep making advances and new versions, and that's a good thing, isn't it? :-)
How far is the whole system now from full inclusion in gcc and simtel distribution?
major new chunks of code are added only on the HEAD branch, if it's in stage 1 of the release schedule (http://gcc.gnu.org/develop.html).
[...]
In the past, there has been lack of interest, lack of resources and IIRC some disappointment how or if at all patches are getting merged into gcc.
So if this merge will ever happen, someone has to bite the bullet to work on the unstable gcc ...
Let's not forget that there are some issues to be solved before this should happen. The following are only the major points that come to my mind right now. I may be missing some, and there are some smaller points as well:
- First of all, get the gcc-3 port stable. (FTR, within a few days before the last alpha, I found 4 memory management related bugs. I fixed them before the release, but on the basis of any reasonable statistics one should expect to find some more in the nearer future.)
- Fix the debug info. (Waldek is working on that ...)
- Clean up the backend patches. Some parts of them are related to the debug info problems, and may be kludges, some more are also debatable, others need some cleanups. I could well understand the GCC developers rejecting such patches, and I don't think it would be a good idea to put bad or dubious patches in GCC now and fix them later.
- Remove automake. This is a necessity for getting the compiler driver in synch (or even close to) that of the C compiler (and all other languages, AFAIK). Of course, this means that the replacement (gp) has to be finished before. If we want to do this well, this means at least going through several betas and probably a number of changes until it is satisfactory for all needs.
- Dropping the gcc-2 support. Of course, the GCC developers won't want to put in code for older GCC versions (even if conditional) in the current code. But this means, either keep two GPC source trees, one with and one without the gcc-2 conditionals (and that means, someone will have to maintain them, since I certainly won't do that; and I can tell you from experience with smaller "divergences" that it will be a boring, error-prone and generally distasteful job ;-), or to wait until gcc-2 support can be removed from GPC at all in good conscience (i.e., in a regular release cycle, like getting gcc-3 support stable in our tests, ask everyone to try it, deprecate gcc-2 support, have a major GPC release with gcc-3 support preferred and gcc-2 support deprecated, and if then no major problems appear, drop gcc-2 support).
Of course, if you really want to, you can "bite the bullet" and try integration right now. But I'm quite sure it will be much more work in total than is doing it in the proper order, and it will be technically dubious solutions (both from the GCC and the GPC viewpoint, in different areas).
OTOH, I don't see any big advantage in hurrying it. It may be easier for distribution makers (so I see your POV, Matthias), but then again, I suppose you have your build scripts in place for the current situation, and changing them to a cleaner (in this regard) style now or later doesn't make a big difference. I don't know about the "simtel distribution" Chuck mentioned -- it's no problem today to make distributions in any form (in source, if wanted, including the GCC sources, already patched possibly; sure, the archive would be a little bigger, some 15 MB instead of 2 MB, but from my impression, most Internet users won't even notice the diffrence today ;-).
Actually I wonder where this "panic" about gcc integration comes from. Since some time, I keep hearing these requests every other week. GPC has been developed for years without such an integration, and I doubt it would have been essentially better if it was integrated -- maybe even worse; currently, when there are severe backend problems (such as the `goto' bug in 2.95 on Solaris/Sparc), there is the recourse to try another GCC version; if it was integrated and tied to one GCC version, we'd depend on that version ...
Finally, if all that doesn't convince you, I'll put it in a more selfish way. The main reason why I do GPC development is that I also use GPC myself, and it's both useful and interesting to improve the tools I'm using. GCC integration doesn't provide any direct advantage to my work using GPC, so I don't feel like putting any unnecessary work in it (which would be caused by hurrying it).
So, everyone who wants to actually help the GCC integration, just pick your job from the list above (or another one I may have missed). So far only Waldek (with the "port" for gcc-3) and Eike (with the manual license change to FDL, which was another requirement) have done so (and I have done some things WRT the Makefiles and in the code which I found also useful independently of the GCC integration ;-).
Frank
Frank Heckenbach wrote:
Matthias Klose wrote:
How far is the whole system now from full inclusion in gcc and simtel distribution?
major new chunks of code are added only on the HEAD branch, if it's in stage 1 of the release schedule (http://gcc.gnu.org/develop.html).
A stage 1 is coming up pretty soon, probably in about a week (as soon as gcc 3.3 branches). It should last for a couple of months.
In the past, there has been lack of interest, lack of resources and IIRC some disappointment how or if at all patches are getting merged into gcc.
So if this merge will ever happen, someone has to bite the bullet to work on the unstable gcc ...
What about using the current GCC development methodology? 1. Create a branch (based on HEAD) in the GCC repos for GPC development 2. Move GPC development for gcc3 over there. 3. Start cleaning up GPC while it's in there. Merge back-end patches as they become clean. 4. Eventually, during some stage 1, merge the branch.
Let's not forget that there are some issues to be solved before this should happen. The following are only the major points that come to my mind right now. I may be missing some, and there are some smaller points as well:
- First of all, get the gcc-3 port stable. (FTR, within a few days before the last alpha, I found 4 memory management related bugs. I fixed them before the release, but on the basis of any reasonable statistics one should expect to find some more in the nearer future.)
Yes; this is pretty much a prerequisite to getting GPC into GCC mainline. I've quite impressed with the current status though, given how bad it was a few months ago.
- Fix the debug info. (Waldek is working on that ...)
I don't know, but I suspect this is not a showstopper for integration, since it doesn't mess with anything else in GCC.
- Clean up the backend patches. Some parts of them are related to the debug info problems, and may be kludges, some more are also debatable, others need some cleanups. I could well understand the GCC developers rejecting such patches, and I don't think it would be a good idea to put bad or dubious patches in GCC now and fix them later.
Yep, this is absolutely needed for integration into mainline. Though not for a branch. Maybe I'll take a look at this.
- Remove automake. This is a necessity for getting the compiler driver in synch (or even close to) that of the C compiler (and all other languages, AFAIK). Of course, this means that the replacement (gp) has to be finished before. If we want to do this well, this means at least going through several betas and probably a number of changes until it is satisfactory for all needs.
Needed eventually, but I don't see why the integration should be held up for this, since it doesn't mess with anything in the rest of GCC.
- Dropping the gcc-2 support. Of course, the GCC developers won't want to put in code for older GCC versions (even if conditional) in the current code. But this means, either keep two GPC source trees, one with and one without the gcc-2 conditionals (and that means, someone will have to maintain them, since I certainly won't do that; and I can tell you from experience with smaller "divergences" that it will be a boring, error-prone and generally distasteful job ;-), or to wait until gcc-2 support can be removed from GPC at all in good conscience (i.e., in a regular release cycle, like getting gcc-3 support stable in our tests, ask everyone to try it, deprecate gcc-2 support, have a major GPC release with gcc-3 support preferred and gcc-2 support deprecated, and if then no major problems appear, drop gcc-2 support).
The other way to do this is a genuine divergence. Keep gcc-2 support (*only*, no gcc-3 support) in a "stable" version, living in the old repos, and only accepting bugfixes. Put a gcc-3-only version into the main gcc repos, and do the vast majority of development there.
I guess your standards for dropping gcc-3 support from development versions 'in good conscience' may be higher than the GCC team's standards for releasing GCC 3.0. ;-)
Of course, if you really want to, you can "bite the bullet" and try integration right now. But I'm quite sure it will be much more work in total than is doing it in the proper order, and it will be technically dubious solutions (both from the GCC and the GPC viewpoint, in different areas).
Hmm. :-) I'm not sure why it would be "much more work", at this point; it looks like exactly the same work. I'm also not sure what 'technically dubious solutions' you're referring to; once the back end patches are cleaned up and the memory management is pretty stable, the other work really can be done equally well in GCC or out of GCC, as far as I can tell.
Actually I wonder where this "panic" about gcc integration comes from. Since some time, I keep hearing these requests every other week. GPC has been developed for years without such an integration, and I doubt it would have been essentially better if it was integrated -- maybe even worse; currently, when there are severe backend problems (such as the `goto' bug in 2.95 on Solaris/Sparc), there is the recourse to try another GCC version; if it was integrated and tied to one GCC version, we'd depend on that version ...
It would have the advantage that when the GCC middle-end/glue code was updated en masse for some small technical reason, the GPC code would be updated simultaneously, rather than falling behind each time and having to catch up again. Several such little changes are happening for GCC 3.4. (The memory management changes are another, earlier example.)
The 'try another GCC version' idea is interesting. But GPC has to be 'ported' to each new GCC version, because the GCC middle-end and back ends are moving targets. So I'm not really sure how much value you get out of it these days.
It's the only 'production-quality' front-end which isn't integrated at the moment, which I think is why so many people would like it integrated.
Finally, if all that doesn't convince you, I'll put it in a more selfish way. The main reason why I do GPC development is that I also use GPC myself, and it's both useful and interesting to improve the tools I'm using. GCC integration doesn't provide any direct advantage to my work using GPC, so I don't feel like putting any unnecessary work in it (which would be caused by hurrying it).
Well, good point there. :-)
So, everyone who wants to actually help the GCC integration, just pick your job from the list above (or another one I may have missed). So far only Waldek (with the "port" for gcc-3) and Eike (with the manual license change to FDL, which was another requirement) have done so (and I have done some things WRT the Makefiles and in the code which I found also useful independently of the GCC integration ;-).
I'll take a look at those back end patches sometime, see how much they can be trimmed down and cleaned up.
--Nathanael
Nathanael Nerode wrote:
- Dropping the gcc-2 support. Of course, the GCC developers won't want to put in code for older GCC versions (even if conditional) in the current code. But this means, either keep two GPC source trees, one with and one without the gcc-2 conditionals (and that means, someone will have to maintain them, since I certainly won't do that; and I can tell you from experience with smaller "divergences" that it will be a boring, error-prone and generally distasteful job ;-), or to wait until gcc-2 support can be removed from GPC at all in good conscience (i.e., in a regular release cycle, like getting gcc-3 support stable in our tests, ask everyone to try it, deprecate gcc-2 support, have a major GPC release with gcc-3 support preferred and gcc-2 support deprecated, and if then no major problems appear, drop gcc-2 support).
The other way to do this is a genuine divergence. Keep gcc-2 support (*only*, no gcc-3 support) in a "stable" version, living in the old repos, and only accepting bugfixes. Put a gcc-3-only version into the main gcc repos, and do the vast majority of development there.
Sorry, not an option for me. Most of my development work are genuine Pascal features (mostly independent of the backend version), and I often use them in my own code (and so do others, I assume). I need a rather stable version for my Pascal programming.
I guess your standards for dropping gcc-3 support from development versions 'in good conscience' may be higher than the GCC team's standards for releasing GCC 3.0. ;-)
You mean gcc-2 suppose, I suppose. Well, my standards are first that I must be confident to use a gcc-3 based GPC for my own programming exclusively (and then of course, whether someone else reports major problems), since if that fails (in a way that I can't easily fix, maybe a serious memory management problem), I'd be quite screwed.
I still hold that it's better to stabilize GPC/gcc-3 now (which now means mostly testing and fixing newly found bugs, and probably fixing the debug-info problems), until we can "afford" to drop gcc-2 (sometime next year I guess). That's really the main thing -- the differences between gcc-3 versions are not so big (at least up to now, and insofar as they affect GPC).
Of course, if you really want to, you can "bite the bullet" and try integration right now. But I'm quite sure it will be much more work in total than is doing it in the proper order, and it will be technically dubious solutions (both from the GCC and the GPC viewpoint, in different areas).
Hmm. :-) I'm not sure why it would be "much more work", at this point; it looks like exactly the same work.
I hope my above explanations make it clear. I'd have to do the Pascal-side development in the gcc-2 tree and the gcc-3 tree simultaneously, or only at the former and port it all over to the latter later.
The point is that the Pascal-side of GPC is a moving target as well (in fact, many changed are planned), and we can't afford to let it stand still during the integration phase.
The current situation (with the `ifdef's) is a good way to pursue both gcc-2 and gcc-3 development at the same time without much duplication of effort. (And we will be able to gradually declare gcc-3 more stable and preferable, and deprecate gcc-2, without any differences in the Pascal features.)
I'm also not sure what 'technically dubious solutions' you're referring to;
I think the automake mechanism by itself is dubious enough. ;-) Maybe it doesn't strictly violate any GCC rule, and maybe the GCC developers won't even care (but I do ;-). At least, it breaks the possibility to have a common driver for all languages (except for the linking of the runtime library which is the only essential difference for (most?) other languages, AFAIK, and will be for GPC once automake is removed).
once the back end patches are cleaned up
That's another point, and here in fact it doesn't matter (WRT the amount of work involved) whether it's done now or later.
I'll take a look at those back end patches sometime, see how much they can be trimmed down and cleaned up.
Thanks.
BTW, a large part of the backend patch is related to sets. I'm not sure if Pascal is the only frontend that uses sets. (I think Chill does/did so as well, but I heard it wasn't maintained anymore). If so, it might be possible to clean it up a bit and tailor it more to Pascal's needs (e.g., in Pascal set_words_big_endian is always 0; set_word_size and set_alignment are always TYPE_PRECISION (long_unsigned_type_node)), so it will need less patches or otherwise settings.
Frank
Maurice Lombardi wrote:
Frank Heckenbach a écrit:
I've uploaded a new alpha version.
Good news !!! Since gpc-3.2.1 for djgpp has been released this week, I have tried to compile this alpha (20021128) with it on djgpp. It works seamlessly, no patches needed beyond the ordinary djgpp and gpc patches. Running the test suite with -g0 there is only one real error on fjf341b
Yes, that's the one known bug with gcc-3 (on IA32).
TEST pipetes2.pas: The process terminated with status 0.
This might be a problem with command.com (if you have this as your default shell under DJGPP). The test program invokes it with the command `exit 42'.
At least my version (Novell Dos 7) seems to work correctly, as tried from bash under DJGPP:
bash$ command.com /c "exit 42" bash$ echo $? 42
If other versions of command.com are broken in this regard, we should maybe change the test program.
I do not know what was wrong with gc-3.1.1 (compiling this alpha with it still crashed), but we can forget about it now.
I guess so.
BTW, are there any systems which require gcc-3.1.1 (and don't work with gcc-3.2.1)? If not, I suggest to drop the gcc-3.1.1 support (which means just removing the diff from the distribution and having one less configuration to test).
Frank
Frank Heckenbach a écrit:
Maurice Lombardi wrote:
Frank Heckenbach a écrit:
TEST pipetes2.pas: The process terminated with status 0.
This might be a problem with command.com (if you have this as your default shell under DJGPP). The test program invokes it with the command `exit 42'.
At least my version (Novell Dos 7) seems to work correctly, as tried from bash under DJGPP:
bash$ command.com /c "exit 42" bash$ echo $? 42
Indeed I obtain
Welcome to bash version 2.04.7(1)-release knautie#1(c:/)$ command.com /c "exit 42" knautie#1(c:/)$ echo $? 0
Maurice
Maurice Lombardi wrote:
Indeed I obtain
Welcome to bash version 2.04.7(1)-release knautie#1(c:/)$ command.com /c "exit 42" knautie#1(c:/)$ echo $? 0
OK, I'm changing the test program.
Frank
-
CBFalconer -
Frank Heckenbach -
Matthias Klose -
Maurice Lombardi -
Nathanael Nerode -
Prof A Olowofoyeku (The African Chief)