This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, gdc] - Merging gdc (GNU D Compiler) into gcc
On Wed, 27 Jun 2012, Iain Buclaw wrote:
> It's copied as including c-common.c / .h causes problems with a fair
> number of references pulled in that need to be stubbed out - also,
> some GCC function attributes that we use do not make any sense to have
> in D code (eg: gnu_inline, artificial, cleanup). It could certainly
> be possible though ... Will need to review this in more detail.
Quite possibly you need to split up c-common so that the parts that can
also be shared with D are in separate files.
> The D frontend is completely independent of the GCC backend, and any
> alterations are purely for portability (eg, the use of real_t rather
> than long double for the representation of floats). There is no
If for portability, I'd hope they wouldn't need to be conditional -
rather, the common repository used for all the compilers using the
dfrontend code should be able to have them, unconditionally, and another
such compiler might have a typedef of real_t to long double if that's what
that other compiler wishes to use. Hopefully you can work with the people
maintaining other such compilers so that there can genuinely be a shared,
portable source base for the shared code, in a public repository used by
all those maintainers, without conditionals based on which compiler it's
used in, and with that shared source base only using an absolute minimum
of headers from whatever compiler it's used in (so only minimal GCC
headers when used in GCC, etc.).
> Likewise, have removed it as is in fact no longer required. The
> "optimize" #undef remains for the time being as it conflicts with the
> name of a member in the D frontend sources. If the D frontend
> followed the C++ Coding Conventions as outlined in
> gcc.gnu.org/wiki/CppConventions then this wouldn't be an issue.
> Though I don't think it has an obligation to being essentially
> disconnected from calling any GCC code.
But it ought to be possible to stop the shared D front end from including
the relevant GCC headers at all, if it has a clean interface to the rest
of GCC....
> Have removed all alloca handling from GDC and replaced with simply
> including libiberty.h.
system.h includes libiberty.h, so direct inclusion of libiberty.h
shouldn't be needed (unless you are trying to avoid using system.h in code
shared with other D compilers).
> https://github.com/D-Programming-GDC/GDC/commits/master
>
>
> I do have a question though, what is available for the transition of
> development from git to svn? Other than a lot of ready and getting
> used to the various switches and commands on my part.
Once there is a front end ready to commit and approved in technical and
GNU policy terms, you'd just do "svn add" on the files to add them to
trunk. It's up to you how you handle keeping the dfrontend/ changes in
sync with an external shared repository (with all changes going to the
external repository first); Ian Taylor may have some automation for that
issue for Go.
--
Joseph S. Myers
joseph@codesourcery.com