This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [gpc] Re: GCC integration?


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)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]