This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [gpc] Re: GCC integration?
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Thorsten Glaser <tg at 66h dot 42h dot de>
- Cc: gpc at gnu dot de, gcc at gcc dot gnu dot org
- Date: Fri, 17 Dec 2004 10:28:49 +0000 (UTC)
- Subject: Re: [gpc] Re: GCC integration?
- References: <E1Cf7Qj-0002Jx-00@hera.math.uni.wroc.pl><Pine.BSO.4.61L.0412170656290.14981@odem.66h.42h.de>
On Fri, 17 Dec 2004, 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.
The benefits of integrating gpc into GCC would arise from its inclusion in
mainline and so in ordinary GCC development, not from its inclusion in old
release branches. All new features need to go on mainline before they can
appear in any release branch.
> 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
I'd consider getting the directory structure right in this way to be
something that should be done before integration in CVS. In general front
ends which are gratuitously different from the rest of those in CVS cause
trouble. Similarly all the criteria in sourcebuild.texi should be met,
and account should be taken of all the cleanups and consistency
improvements that have gone into GCC CVS in recent years, though we can
always help with cleanups, consistency and removal of obsolete code only
relevant for older GCC versions after it goes into CVS. (But do at least
compare files such as Make-lang.in with versions from newer front ends
such as gfortran and give specific justification where things are done
differently from the usual way in GCC, and update the coding style to that
now used in GCC, e.g. ISO C90 can be presumed so there should be new-style
function definitions and unconditional use of prototypes; ` should no
longer be used as a left quote in diagnostics; generated files in CVS
should be avoided where possible, with the release script generating those
needed in releases and update_web_docs generating those needed to build
the online manuals. When you actually have a version that works with
mainline CVS ready to integrate, plenty of people will be willing to help
with finding such issues.)
The gpc testsuite should also move to under gcc/testsuite.
> 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.
When code is in GCC mainline people will do global cleanups which will
include removing code that isn't relevant for mainline. If you want to do
releases of GPC with newer GPC code and older GCC code, how you do so is
up to you, but it will need to be off branches or other development trees.
(In the case of Ada, the code that depends on the GCC back end is very
localised in gigi.)
> While it might also be worthwhile to integrate
> Hiroaki Etoh's ProPolice SSP, and probably other
Again, features cannot be integrated in release branches before they are
in mainline, and they cannot go in mainline if their developers will not
discuss, explain and adapt them in accordance with the usual development
procedures. You will need to be familiar with these procedures
(develop.html, contribute.html, codingconventions.html and much of the
rest of the GCC website) to include GPC within GCC development.
> 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?).
Distributors do backport fixes where appropriate. They also integrate GPC
into their releases in some cases.
> for the more common platforms; I doubt gpc will make
> it into mainline before it runs on almost all platforms,
You can put
build_by_default=no
in p/config-lang.in until it is sufficiently ready.
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
jsm@polyomino.org.uk (personal mail)
joseph@codesourcery.com (CodeSourcery mail)
jsm28@gcc.gnu.org (Bugzilla assignments and CCs)