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