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