This is the mail archive of the 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: Merging gdc (GNU D Compiler) into gcc

On 4 October 2011 15:02, Ian Lance Taylor <> wrote:
> Iain Buclaw <> writes:
>> I've have received news from Walter Bright that the license of the D
>> frontend has been assigned to the FSF. As the current maintainer of
>> GDC, I would like to get this moved forward, starting with getting the
>> ball rolling. What would need to be done? And what are the processes
>> required? (ie: passing the project through to technical review.)
>> The current home of GDC is here:
> Some preliminary comments.
> Do you plan to move primary maintenance of the D frontend into gcc
> proper, or do you plan the mirror the D frontend from an external
> repository?

Kind of both.

It is my goal to move primary maintenance of GDC into GCC. GDC is
however in two parts, one which is the D frontend as maintained by
Digital Mars, the other is the GCC interface/bindings between the D
frontend and GCC backend as is what I maintain and develop.

The active development of the D frontend would continue to be mirrored
in an external repository, but will occasionally be merged into GDC

> Are there any additional external dependencies required to build the D
> frontend or the D runtime support?

There are no other dependencies outside of what is required to build GCC.

> I note that you have some patches to gcc proper; those patches need to
> submitted individually for separate review.

These patches address two areas of the D language:
1) D calling convention.
2) Naked functions on i386 and x86_64

Some work would need to be done on naked functions at least first so
that changes required are only to gcc/config. I would be grateful if I
could get pointed in the right direction for implementing naked as a
function attribute for i386 so all frontends could benefit.

I will get on the case once I'm happy to submit them though.

> The D frontend code does not appear to follow the gcc coding
> conventions. ?I'm not sure whether we should worry about that or not.

I have a vim macro which can sort that out. :o)

> The D frontend code appears to be under the GPLv2. ?The gcc project
> would prefer GPLv3.

I have no problem re-licensing the project to GPLv3.

> The D runtime appears to be in a subdirectory of gcc/d. ?Ordinarily we
> would prefer that it be in a separate toplevel directory, e.g.,
> libdruntime.

The set-up build script that is provided with the gdc development
folder makes symlinks from gcc/d/ to a libphobos toplevel directory.

> There is a directory gcc/d/zlib, but gcc already has a top-level zlib
> directory.

Zlib there is the version released with the D Phobos library, it is
slightly newer. But is harmless to remove.

> There is a list of most of the requirements for a new frontend at
> . ?Work through the
> list and make sure that everything is handled.

First question that pops up after having a quick look is, are there
any tips around for writing the scripts for the testsuite? I'm not too
familiar with Dejagnu, and the current testsuite used for GDC D2
development is written in make.

> I would like to see this happen, thanks for pushing forward.
> Ian


Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

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