From: Thorsten Glaser tg@66h.42h.de ^^^^^^^^^^^^^ That is the cause for this resend, fixed that now. To: gpc@gnu.de Cc: gcc@gcc.gnu.org Subject: [gpc] Re: GCC integration?
Waldek Hebisch dixit:
(cross-posted to gcc list, please reply to the gpc list)
appling the patch form `diffs' subdirectory. Going beyond that would be mostly wasted effort, because gcc-3.4.x and coming 4.x are different enough (so one would have to re-do the work for
Exactly this is the cause for the following request of mine:
Since gcc 4.0 will be out of the door not in less than two months from now, and given that gcc 4.1, which ought to solve at least the basic problems with tree-ssa etc. is not even in sight yet, I propose that there will be a gcc-3.5 release with support for Pascal, based upon gcc-3.4, current gpc and Waldek's patches.
This would be great since we already had the new directory layout (what I would greatly like to see for Ada and Pascal is that their RTS moves from gcc/p/ to libgpc/ ASAP), and the gcc-3.4/3.5 specific diffs integrated into the core, while the backend patches for gcc 3.3 and older are still available (I don't think Frank is going to throw them away after the integration), and so, if you do _not_ remove the ifdefs from gcc/p/*, you could do another standalone GPC release based upon the code in the gcc-3.5 development tree.
While it might also be worthwhile to integrate Hiroaki Etoh's ProPolice SSP, and probably other fixes (Apple stuff?), this would mean gcc 3.5 must be an "official" release. If the SC really is reluctant to do so, it might be feasible to do a "gpc+gcc 3.5" version, developed as a branch in the gcc cvs, but not endorsed by the SC. (Of course, if there'd be interest, one could add ProPolice to that branch as well, unless you really want it to be only for your gpc-specific work. If there is interest, I myself could try to get cvs ci access to gcc.gnu.org - I've already signed the relevant forms, and etoh has, too - and integrate the current propolice; I'm already doing this for the gcc contained in my OS at the moment).
For others, developers, especially OS vendors, this would also be great, because history has shown that gcc 3.x branches tend to end after 3.x.3 or 3.x.4, and for the aforementioned reasons 4.0/4.1 will not gain wide acceptance outside of Gentoo (j/k) soon; if one were to incorporate generic 3.x bugfixes and maybe backport 4.x bugfixes into a 3.5 series, this could not only get much adoption, but maybe support from the large (e.g.) GNU/Linux vendors (Novell?).
This support would lead to a faster distribution of gpc to "the masses" than releasing a standalone gpc version now and then integrating it into 4.1/4.2 ever could. Besides, support for 3.4 is "almost" done for the more common platforms; I doubt gpc will make it into mainline before it runs on almost all platforms, and having it in gcc cvs will surely help to both get more eyes on the code (Nathanael said something like this IIRC) and get these who do changes to the backend more aware of gpc.
Just my 0.02 EUR, //mirabile
Thorsten Glaser wrote:
Since gcc 4.0 will be out of the door not in less than two months from now, and given that gcc 4.1, which ought to solve at least the basic problems with tree-ssa etc. is not even in sight yet, I propose that there will be a gcc-3.5 release with support for Pascal, based upon gcc-3.4, current gpc and Waldek's patches.
This would be great since we already had the new directory layout (what I would greatly like to see for Ada and Pascal is that their RTS moves from gcc/p/ to libgpc/ ASAP), and the gcc-3.4/3.5 specific diffs integrated into the core, while the backend patches for gcc 3.3 and older are still available (I don't think Frank is going to throw them away after the integration),
After the integration as I plan it (i.e., after the next major GPC release), I probably will "throw them away". Of course, they'll be still available in older archives, but if they're not maintained anymore, they'll probably become useless sooner or later.
Nobody said to stop integration work. It's about two things. To get stuff in at all and in the correct directories, and to adapt the code (esp. for gcc4). Start with the easier.
I don't quite agree. There's been much talk of those directories, but I don't see it as a big issue. It will involve moving some files (trivial) and adjusting the RTS build (which is partly broken and outdated anyway). All in all, it can probably done easily in a day by someone who's familiar with the issues (I'm only partly, currently).
Since early integration causes some "friction", as I tried to explain, I'd favour doing the hard stuff first (i.e., the necessary changes for newer backends which have to be done sometime anyway), and do the last (easy) step when we can be confident that we won't have to go back.
Marcel Cox dixit:
- I think doing major GPC integration work now based on GCC 3.x is
just a waste of resources
There is not much to do. I integrated gpc into a BSD in-tree gcc once, and besides having to rewrite some stuff for BSD make and applying the diffs correctly, there was next to no work involved.
Yes, that's the easy part as Waldek noted. Adjusting to the backend and infrastructural changes (such as TreeSSA) is what takes most of the work.
Frank
-
Frank Heckenbach -
Thorsten Glaser