Merging gdc (GNU D Compiler) into gcc

Merging gdc (GNU D Compiler) into gcc

[Iain Buclaw]

Hi,

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: https://bitbucket.org/goshawk/gdc


Regards
-- 
Iain Buclaw

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

Re: Merging gdc (GNU D Compiler) into gcc

[Andrew Haley]

On 10/04/2011 08:08 AM, Iain Buclaw wrote:

> 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.)

In general we welcome contributions like this.  The biggest problem in
the past has always been continued maintainership: some front- ends
have been abandoned because of a lack of TLC.  As the current GDC
maintainer, I'm sure you know that keeping up with gcc development
requires constant attention.  Do you have anyone who could be a
co-maintainer?

Andrew.

Re: Merging gdc (GNU D Compiler) into gcc

[Ian Lance Taylor]

Iain Buclaw <ibuclaw@ubuntu.com> 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: https://bitbucket.org/goshawk/gdc

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?

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

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

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.

The D frontend code appears to be under the GPLv2.  The gcc project
would prefer 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.

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

There is a list of most of the requirements for a new frontend at
http://gcc.gnu.org/onlinedocs/gccint/Front-End.html .  Work through the
list and make sure that everything is handled.

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

Ian

Re: Merging gdc (GNU D Compiler) into gcc

[Joseph S. Myers]

On Tue, 4 Oct 2011, Iain Buclaw wrote:

> Hi,
> 
> 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.)

Thanks for working on this.  I think Ian covered the main technical 
points.

Was Digital Mars the only copyright holder?  I see the assignment for

GCC     Digital Mars    2011-10-3
Assigns Past and Future Changes to the GNU D Compiler

in copyright.list - if any parts (at least any GCC-specific parts in the 
front end as opposed to runtime libraries) have other copyright holders, 
they will also need to have assignments (and any significant changes to 
GCC outside the front end will similarly need to be covered by 
assignments).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Merging gdc (GNU D Compiler) into gcc

[Iain Buclaw]

On 4 October 2011 09:41, Andrew Haley <aph@redhat.com> wrote:
> On 10/04/2011 08:08 AM, Iain Buclaw wrote:
>
>> 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.)
>
> In general we welcome contributions like this.  The biggest problem in
> the past has always been continued maintainership: some front- ends
> have been abandoned because of a lack of TLC.  As the current GDC
> maintainer, I'm sure you know that keeping up with gcc development
> requires constant attention.  Do you have anyone who could be a
> co-maintainer?
>
> Andrew.
>

There is no one else who actively co-maintains the GCC side of GDC at
this current time, only people who help out with support on a
particular platform or architecture. I do hope this will change over
the next year though.

-- 
Iain Buclaw

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

Re: Merging gdc (GNU D Compiler) into gcc

[Iain Buclaw]

On 4 October 2011 15:02, Ian Lance Taylor <iant@google.com> wrote:
> Iain Buclaw <ibuclaw@ubuntu.com> 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: https://bitbucket.org/goshawk/gdc
>
> 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
project.

> 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
> http://gcc.gnu.org/onlinedocs/gccint/Front-End.html .  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
>

Cheers.

-- 
Iain Buclaw

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

Re: Merging gdc (GNU D Compiler) into gcc

[Andrew Pinski]

On Tue, Oct 4, 2011 at 12:30 PM, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
> 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.

Does D really require a new calling convention?  Also does it really
require naked support?  I think naked support is a bad idea and people
who require naked support should be writing an assembly function
wrapper.

Thanks,
Andrew Pinski

Re: Merging gdc (GNU D Compiler) into gcc

[Iain Buclaw]

On 4 October 2011 17:50, Joseph S. Myers <joseph@codesourcery.com> wrote:
> On Tue, 4 Oct 2011, Iain Buclaw wrote:
>
>> Hi,
>>
>> 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.)
>
> Thanks for working on this.  I think Ian covered the main technical
> points.
>
> Was Digital Mars the only copyright holder?  I see the assignment for
>
> GCC     Digital Mars    2011-10-3
> Assigns Past and Future Changes to the GNU D Compiler
>
> in copyright.list - if any parts (at least any GCC-specific parts in the
> front end as opposed to runtime libraries) have other copyright holders,
> they will also need to have assignments (and any significant changes to
> GCC outside the front end will similarly need to be covered by
> assignments).
>

The original copyrights for the GDC D front-end for GCC are in the
name of David Friedman, who has been MIA since 2007.  Since the
project has been revived, all changes and additions have been
copyrighted in my name, Michael's, and Vincenzo's.  Would I require
approval of these people to assign ownership over to FSF?

Regards
-- 
Iain Buclaw

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

Re: Merging gdc (GNU D Compiler) into gcc

[Joseph S. Myers]

On Tue, 4 Oct 2011, Iain Buclaw wrote:

> The original copyrights for the GDC D front-end for GCC are in the
> name of David Friedman, who has been MIA since 2007.  Since the
> project has been revived, all changes and additions have been
> copyrighted in my name, Michael's, and Vincenzo's.  Would I require
> approval of these people to assign ownership over to FSF?

In the absence of permission from the FSF to do otherwise in a particular 
case (such permission would be sought via the Steering Committee, via this 
list), all significant contributors to front ends need to have papers 
(assignment or disclaimer) on file at the FSF.  
<http://www.gnu.org/prep/maintain/html_node/Legally-Significant.html> 
states what is significant.  Papers may be assignments from individuals 
with disclaimers from any employer with a potential claim, or they may be 
corporate assignments from an employer owning the rights.  (Disclaimers to 
the public domain are also possible as an alternative to assignments.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Merging gdc (GNU D Compiler) into gcc

[Iain Buclaw]

On 4 October 2011 20:36, Andrew Pinski <pinskia@gmail.com> wrote:
> On Tue, Oct 4, 2011 at 12:30 PM, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
>> 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.
>
> Does D really require a new calling convention?  Also does it really
> require naked support?  I think naked support is a bad idea and people
> who require naked support should be writing an assembly function
> wrapper.
>
> Thanks,
> Andrew Pinski
>

Naked functions are part of the D spec, and I would have to remove a
few areas of the D runtime library if they were to go (I may get a
number emails from D users too asking where it has gone).

The D calling convention is one thing I can cope just fine without. It
is needed more for use with some naked functions in the D runtime
library.  The major quirk of the D ABI really is that routines will
return floating point return values on the FPU stack, and expects this
to be cleaned off by the caller, even if they are not used. I can
instead fix the D runtime library if it is that much of a problem.

Regards
-- 
Iain Buclaw

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

Re: Merging gdc (GNU D Compiler) into gcc

[Tom Tromey]

>>>>> "Iain" == Iain Buclaw <ibuclaw@ubuntu.com> writes:

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

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

You could alternatively update the version in gcc.

Tom

Re: Merging gdc (GNU D Compiler) into gcc

[David Brown]

On 04/10/11 21:36, Andrew Pinski wrote:
> On Tue, Oct 4, 2011 at 12:30 PM, Iain Buclaw<ibuclaw@ubuntu.com>  wrote:
>> 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.
>
> Does D really require a new calling convention?  Also does it really
> require naked support?  I think naked support is a bad idea and people
> who require naked support should be writing an assembly function
> wrapper.
>
> Thanks,
> Andrew Pinski
>


"naked" functions are often useful in embedded systems, and are 
therefore useful (and implemented) on many gcc targets.  It would make 
sense to have the attribute available universally in gcc, if that 
doesn't involve a lot of extra work, even though it is of little use on 
"big" systems (Linux, Windows, etc.).

mvh.,

David

Re: Merging gdc (GNU D Compiler) into gcc

[David Brown]

On 04/10/11 21:36, Andrew Pinski wrote:
> On Tue, Oct 4, 2011 at 12:30 PM, Iain Buclaw<ibuclaw@ubuntu.com>  wrote:
>> 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.
>
> Does D really require a new calling convention?  Also does it really
> require naked support?  I think naked support is a bad idea and people
> who require naked support should be writing an assembly function
> wrapper.
>
> Thanks,
> Andrew Pinski
>


"naked" functions are often useful in embedded systems, and are 
therefore useful (and implemented) on many gcc targets.  It would make 
sense to have the attribute available universally in gcc, if that 
doesn't involve a lot of extra work, even though it is of little use on 
"big" systems (Linux, Windows, etc.).

mvh.,

David

Re: Merging gdc (GNU D Compiler) into gcc

[Andrew Pinski]

On Tue, Oct 4, 2011 at 2:40 PM, David Brown <david.brown@hesbynett.no> wrote:
> "naked" functions are often useful in embedded systems, and are therefore
> useful (and implemented) on many gcc targets.  It would make sense to have
> the attribute available universally in gcc, if that doesn't involve a lot of
> extra work, even though it is of little use on "big" systems (Linux,
> Windows, etc.).

Is it really useful if you can have a small top-level inline-asm wrapper?

-- Pinski

Re: Merging gdc (GNU D Compiler) into gcc

[Ian Lance Taylor]

Iain Buclaw <ibuclaw@ubuntu.com> writes:

> On 4 October 2011 20:36, Andrew Pinski <pinskia@gmail.com> wrote:
>> On Tue, Oct 4, 2011 at 12:30 PM, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
>>> 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.
>>
>> Does D really require a new calling convention?  Also does it really
>> require naked support?  I think naked support is a bad idea and people
>> who require naked support should be writing an assembly function
>> wrapper.
>>
>> Thanks,
>> Andrew Pinski
>>
>
> Naked functions are part of the D spec, and I would have to remove a
> few areas of the D runtime library if they were to go (I may get a
> number emails from D users too asking where it has gone).
>
> The D calling convention is one thing I can cope just fine without. It
> is needed more for use with some naked functions in the D runtime
> library.  The major quirk of the D ABI really is that routines will
> return floating point return values on the FPU stack, and expects this
> to be cleaned off by the caller, even if they are not used. I can
> instead fix the D runtime library if it is that much of a problem.

I don't personally have a problem with naked function support.  If it is
part of the D language I think it is reasonable to add it to gcc
backends.  This will presumably require some new target hook to see if
the functionality is available.

Using a different ABI for ordinary functions seem at first glance to be
a mistake, because it hurts interoperability with code not written in D.
I guess if this is implemented it would require some other target hook.

Ian

Re: Merging gdc (GNU D Compiler) into gcc

[Ian Lance Taylor]

Iain Buclaw <ibuclaw@ubuntu.com> writes:

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

Well, Go does set a precedent for this.  The main issue here is that
this means that there is (another) directory containing source code that
the gcc maintainers can't update.  This is workable if the D frontend
does not #include any gcc header files or call any gcc functions.  That
is, if it is truly standalone.  (The Go frontend is not yet in this
state, although I am slowly working toward it.)


> 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.

Needs a target hook in target.def and a new attribute probably in
c-family/c-common.c.  The new attribute would check the target hook to
see whether the backend supports it.


>> 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.

That is kind of awkward, though--why not just set up libphobos in the
first place?  I understand this may require two directories to be
mirrored.


> 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.

DejaGNU is too horrible for me to talk about.  I can't recommend
anything other than blind copying of existing scripts.

Ian

Re: Merging gdc (GNU D Compiler) into gcc

[Iain Buclaw]

On 5 October 2011 00:10, Ian Lance Taylor <iant@google.com> wrote:
> Iain Buclaw <ibuclaw@ubuntu.com> writes:
>
>> The active development of the D frontend would continue to be mirrored
>> in an external repository, but will occasionally be merged into GDC
>> project.
>
> Well, Go does set a precedent for this.  The main issue here is that
> this means that there is (another) directory containing source code that
> the gcc maintainers can't update.  This is workable if the D frontend
> does not #include any gcc header files or call any gcc functions.  That
> is, if it is truly standalone.  (The Go frontend is not yet in this
> state, although I am slowly working toward it.)
>
>

The D frontend does not include any gcc headers or call any gcc functions.

>> 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.
>
> Needs a target hook in target.def and a new attribute probably in
> c-family/c-common.c.  The new attribute would check the target hook to
> see whether the backend supports it.
>
>
>>> 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.
>
> That is kind of awkward, though--why not just set up libphobos in the
> first place?  I understand this may require two directories to be
> mirrored.
>
>

The gcc/d folder is only structured as it is now because gdc code is
shipped as a separate entity from gcc, that you can then apply to any
version of gcc that is supported.  This would no longer be the case if
merged in.  I assume best thing to do for me to get started in the
*doing* would be to set-up a new branch prep'd up as I intend for it
to be if this were to be moved forward.

>> 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.
>
> DejaGNU is too horrible for me to talk about.  I can't recommend
> anything other than blind copying of existing scripts.
>

:-)

Regards
-- 
Iain Buclaw

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

Re: Merging gdc (GNU D Compiler) into gcc

[David Brown]

On 04/10/2011 23:47, Andrew Pinski wrote:
> On Tue, Oct 4, 2011 at 2:40 PM, David Brown<david.brown@hesbynett.no>  wrote:
>> "naked" functions are often useful in embedded systems, and are therefore
>> useful (and implemented) on many gcc targets.  It would make sense to have
>> the attribute available universally in gcc, if that doesn't involve a lot of
>> extra work, even though it is of little use on "big" systems (Linux,
>> Windows, etc.).
>
> Is it really useful if you can have a small top-level inline-asm wrapper?
>

The "naked" attribute is used precisely when you don't want any wrapper 
or other code that you don't absolutely need.

An example of use is when you want to write the prologue and epilogue 
manually - perhaps the compiler's standard interrupt function prologue 
and epilogue are not quite good enough for a special case, so you write 
your own inline assembly.  You don't want the compiler to generate 
additional register saves, frame manipulation, etc.

Some toolchains are configured to have a series of "init" sections at 
startup (technically, that's a matter of the default linker scripts and 
libraries rather than the compiler).  You can get code to run at 
specific times during startup by placing the instructions directly 
within these sections - but it must be "raw" instructions, not function 
definitions (and definitely no "return" statement).  The stack may not 
be defined at this stage - perhaps you are using such code to initialise 
the memory system or do other low-level setup.  For an example, see this 
link:

<http://www.nongnu.org/avr-libc/user-manual/mem_sections.html>


I've also used "naked" functions to provide a place to store specific 
assembly code - I prefer to use inline assembly in C rather than a 
separate assembly module.

RTOS'es often use "naked" in connection with tasks and task switching. 
After the RTOS has gone to all the effort of saving the registers and 
task context, it needs to jump into the next task without there being 
more overhead of stored registers.  On small RISC microcontrollers, it's 
possible for the register bank to be a significant proportion of the 
size of the chip's ram - you don't want to waste the space or the time 
saving things unnecessarily.


Using the "naked" attribute means a little more of such code can be 
written in C, and a little less needs to be written in assembly.  That's 
a good thing.  And making "naked" consistent across more gcc ports means 
a little more of such code can be cross-target portable, which is also a 
good thing.  You are never going to eliminate all target-specific parts 
of such code, nor can you eliminate all assembly - but "naked" is a step 
in that direction.


While I'm on the subject, it would be /very/ nice if the gcc port 
maintainers agreed on function (and data) attributes.  Clearly there 
will be some variation between target ports, but surely it would be 
easier to write, port and maintain if there were more consistency.  From 
a user's viewpoint, it is hard to understand why some targets use 
"long_call" attributes and others use "longcall" to do the same thing, 
or why there are a dozen different ways to declare an interrupt function 
on different architectures.  If these can be combined, it would be less 
effort for the port maintainers, easier for users, and less 
documentation.  It might also make it easier for useful attributes (like 
"naked", or "critical") to spread to other target ports.

mvh.,

David

Re: Merging gdc (GNU D Compiler) into gcc

[David Brown]

On 04/10/2011 23:47, Andrew Pinski wrote:
> On Tue, Oct 4, 2011 at 2:40 PM, David Brown<david.brown@hesbynett.no>  wrote:
>> "naked" functions are often useful in embedded systems, and are therefore
>> useful (and implemented) on many gcc targets.  It would make sense to have
>> the attribute available universally in gcc, if that doesn't involve a lot of
>> extra work, even though it is of little use on "big" systems (Linux,
>> Windows, etc.).
>
> Is it really useful if you can have a small top-level inline-asm wrapper?
>

The "naked" attribute is used precisely when you don't want any wrapper 
or other code that you don't absolutely need.

An example of use is when you want to write the prologue and epilogue 
manually - perhaps the compiler's standard interrupt function prologue 
and epilogue are not quite good enough for a special case, so you write 
your own inline assembly.  You don't want the compiler to generate 
additional register saves, frame manipulation, etc.

Some toolchains are configured to have a series of "init" sections at 
startup (technically, that's a matter of the default linker scripts and 
libraries rather than the compiler).  You can get code to run at 
specific times during startup by placing the instructions directly 
within these sections - but it must be "raw" instructions, not function 
definitions (and definitely no "return" statement).  The stack may not 
be defined at this stage - perhaps you are using such code to initialise 
the memory system or do other low-level setup.  For an example, see this 
link:

<http://www.nongnu.org/avr-libc/user-manual/mem_sections.html>


I've also used "naked" functions to provide a place to store specific 
assembly code - I prefer to use inline assembly in C rather than a 
separate assembly module.

RTOS'es often use "naked" in connection with tasks and task switching. 
After the RTOS has gone to all the effort of saving the registers and 
task context, it needs to jump into the next task without there being 
more overhead of stored registers.  On small RISC microcontrollers, it's 
possible for the register bank to be a significant proportion of the 
size of the chip's ram - you don't want to waste the space or the time 
saving things unnecessarily.


Using the "naked" attribute means a little more of such code can be 
written in C, and a little less needs to be written in assembly.  That's 
a good thing.  And making "naked" consistent across more gcc ports means 
a little more of such code can be cross-target portable, which is also a 
good thing.  You are never going to eliminate all target-specific parts 
of such code, nor can you eliminate all assembly - but "naked" is a step 
in that direction.


While I'm on the subject, it would be /very/ nice if the gcc port 
maintainers agreed on function (and data) attributes.  Clearly there 
will be some variation between target ports, but surely it would be 
easier to write, port and maintain if there were more consistency.  From 
a user's viewpoint, it is hard to understand why some targets use 
"long_call" attributes and others use "longcall" to do the same thing, 
or why there are a dozen different ways to declare an interrupt function 
on different architectures.  If these can be combined, it would be less 
effort for the port maintainers, easier for users, and less 
documentation.  It might also make it easier for useful attributes (like 
"naked", or "critical") to spread to other target ports.

mvh.,

David

Re: Merging gdc (GNU D Compiler) into gcc

[Andi Kleen]

David Brown <david@westcontrol.com> writes:
>
> Some toolchains are configured to have a series of "init" sections at
> startup (technically, that's a matter of the default linker scripts
> and libraries rather than the compiler).  You can get code to run at
> specific times during startup by placing the instructions directly
> within these sections - but it must be "raw" instructions, not
> function definitions (and definitely no "return" statement).

Note that this only works with modern gcc with -fno-reorder-toplevel,
which disables some optimizations, and is currently broken in several
ways with LTO (in progress of being fixed)

Normally you don't get any defined order in these sections, both
unit-at-a-time and LTO do reorder. The linker may also in some
circumstances.

So it's somewhat dangerous to rely on.

-Andi

Re: Merging gdc (GNU D Compiler) into gcc

[David Brown]

On 05/10/2011 12:00, Andi Kleen wrote:
> David Brown<david@westcontrol.com>  writes:
>>
>> Some toolchains are configured to have a series of "init" sections at
>> startup (technically, that's a matter of the default linker scripts
>> and libraries rather than the compiler).  You can get code to run at
>> specific times during startup by placing the instructions directly
>> within these sections - but it must be "raw" instructions, not
>> function definitions (and definitely no "return" statement).
>
> Note that this only works with modern gcc with -fno-reorder-toplevel,
> which disables some optimizations, and is currently broken in several
> ways with LTO (in progress of being fixed)
>

You should not need to worry about re-ordering code within a module 
unless you have several pieces of code that have to be put into the same 
"initX" section in a specific order.  And if that's the case, then you 
can just put all that code within the one "naked" function.

Of course, you have to put the code in the right section.  An example 
(from the avr-libc documentation) is:

void my_init_portb (void) __attribute__ ((naked))
     __attribute__ ((section (".init3")));
void my_init_portb (void)
{
         PORTB = 0xff;
         DDRB = 0xff;
}


LTO might well remove that function unless you also use the "used" 
attribute - although hopefully the "Keep" directive in the linker script 
file will do the same thing.

But I can't see why the -fno-reorder-toplevel flag would be needed here.

> Normally you don't get any defined order in these sections, both
> unit-at-a-time and LTO do reorder. The linker may also in some
> circumstances.
>

You need a linker script that puts these sections in the right place, of 
course.

> So it's somewhat dangerous to rely on.
>
> -Andi
>

Re: Merging gdc (GNU D Compiler) into gcc

[David Brown]

On 05/10/2011 12:00, Andi Kleen wrote:
> David Brown<david@westcontrol.com>  writes:
>>
>> Some toolchains are configured to have a series of "init" sections at
>> startup (technically, that's a matter of the default linker scripts
>> and libraries rather than the compiler).  You can get code to run at
>> specific times during startup by placing the instructions directly
>> within these sections - but it must be "raw" instructions, not
>> function definitions (and definitely no "return" statement).
>
> Note that this only works with modern gcc with -fno-reorder-toplevel,
> which disables some optimizations, and is currently broken in several
> ways with LTO (in progress of being fixed)
>

You should not need to worry about re-ordering code within a module 
unless you have several pieces of code that have to be put into the same 
"initX" section in a specific order.  And if that's the case, then you 
can just put all that code within the one "naked" function.

Of course, you have to put the code in the right section.  An example 
(from the avr-libc documentation) is:

void my_init_portb (void) __attribute__ ((naked))
     __attribute__ ((section (".init3")));
void my_init_portb (void)
{
         PORTB = 0xff;
         DDRB = 0xff;
}


LTO might well remove that function unless you also use the "used" 
attribute - although hopefully the "Keep" directive in the linker script 
file will do the same thing.

But I can't see why the -fno-reorder-toplevel flag would be needed here.

> Normally you don't get any defined order in these sections, both
> unit-at-a-time and LTO do reorder. The linker may also in some
> circumstances.
>

You need a linker script that puts these sections in the right place, of 
course.

> So it's somewhat dangerous to rely on.
>
> -Andi
>

Re: Merging gdc (GNU D Compiler) into gcc

[Walter Bright]

On 10/4/2011 12:08 AM, Iain Buclaw wrote:
> 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: https://bitbucket.org/goshawk/gdc
>
>

I did this for the express purpose of enabling GDC to be merged into gcc. Being 
part of gcc will be a great boon to the D community and to the gcc user 
community at large. Iain is in charge of the GDC project, has been doing a 
fantastic job, and has my full support and the support of the D community. Let's 
make this happen!

Re: Merging gdc (GNU D Compiler) into gcc

[Iain Buclaw]

On 4 October 2011 09:41, Andrew Haley <aph@redhat.com> wrote:
> On 10/04/2011 08:08 AM, Iain Buclaw wrote:
>
>> 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.)
>
> In general we welcome contributions like this.  The biggest problem in
> the past has always been continued maintainership: some front- ends
> have been abandoned because of a lack of TLC.  As the current GDC
> maintainer, I'm sure you know that keeping up with gcc development
> requires constant attention.  Do you have anyone who could be a
> co-maintainer?
>
> Andrew.
>

(Apparently the first message from my phone didn't get sent through earlier.)

I have spoken to Daniel, I can confirm he is willing to help
co-maintain GDC with me.

I have no intention of letting this project go abandoned, nor do I see
any end in sight of my continued maintaining and development of gdc. I
understand your concerns that GDC might not receive the care it
requires to keep up with the rest of GCC, and you can have my word
that I will do my utmost to ensure this will never be the case.

Regards
-- 
Iain Buclaw

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

Re: Merging gdc (GNU D Compiler) into gcc

[Dave Korn]

On 05/10/2011 04:56, Iain Buclaw wrote:
> On 5 October 2011 00:10, Ian Lance Taylor <iant@google.com> wrote:
>> Iain Buclaw <ibuclaw@ubuntu.com> writes:
>>

>>> 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.
>> DejaGNU is too horrible for me to talk about.  I can't recommend
>> anything other than blind copying of existing scripts.
>>
> 
> :-)

  There are at least some docs online:

http://gcc.gnu.org/wiki/TestCaseWriting
http://gcc.gnu.org/wiki/HowToPrepareATestcase
http://gcc.gnu.org/onlinedocs/gccint/Testsuites.html#Testsuites

  The DejaGnu manual is available online
(http://www.gnu.org/s/dejagnu/#documentation), although it's not very
GCC-specific; the most useful bit is the list of command-line options
(http://www.gnu.org/s/dejagnu/manual/x844.html#optiondefs) that you can pass
by setting RUNTESTFLAGS="..." on the 'make check' command-line.  If you're
having real trouble understanding what's going on in a test script, setting
RUNTESTFLAGS="-v -v -v --strace 30" will show you all the tcl commands being
executed in the log file.

  And as Ian says, most people just copy how it's done in existing scripts.


    cheers,
      DaveK

Re: Merging gdc (GNU D Compiler) into gcc

[Iain Buclaw]

On 4 October 2011 08:08, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
> Hi,
>
> 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: https://bitbucket.org/goshawk/gdc
>


This has been rather long wait from my side of the pond (moving has
taken away quite some time from my side).  But I'll be in a position
to begin discussion on arrangements this weekend for patches to be
submitted for GCC 4.8.

I would be grateful if we could start and maintain discussions on
making this happen, and I hope some sort of agreement could be reached
by the end of the month.


Regards

-- 
Iain Buclaw

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

Re: Merging gdc (GNU D Compiler) into gcc

[Dave Korn]

On 11/04/2012 15:12, Iain Buclaw wrote:

> This has been rather long wait from my side of the pond (moving has
> taken away quite some time from my side).  But I'll be in a position
> to begin discussion on arrangements this weekend for patches to be
> submitted for GCC 4.8.
> 
> I would be grateful if we could start and maintain discussions on
> making this happen, and I hope some sort of agreement could be reached
> by the end of the month.

  Well, we're just out of release freeze and back in stage 1, so there should
be plenty of time and not too much problem even if it does kick up some issues
that need to be dealt with after the fact.  What state are your patches in?

    cheers,
      DaveK

Re: Merging gdc (GNU D Compiler) into gcc

[Iain Buclaw]

On 11 April 2012 15:12, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
> On 4 October 2011 08:08, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
>> Hi,
>>
>> 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: https://bitbucket.org/goshawk/gdc
>>
>
>
> This has been rather long wait from my side of the pond (moving has
> taken away quite some time from my side).  But I'll be in a position
> to begin discussion on arrangements this weekend for patches to be
> submitted for GCC 4.8.
>
> I would be grateful if we could start and maintain discussions on
> making this happen, and I hope some sort of agreement could be reached
> by the end of the month.
>

I would like to give a gentle reminder of this.  Where should I be
posting the proposed patches to? The frontend and runtime library
alone would be a few megabytes in size.


Regards

-- 
Iain Buclaw

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

Re: Merging gdc (GNU D Compiler) into gcc

[Richard Guenther]

On Thu, May 10, 2012 at 11:37 AM, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
> On 11 April 2012 15:12, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
>> On 4 October 2011 08:08, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
>>> Hi,
>>>
>>> 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: https://bitbucket.org/goshawk/gdc
>>>
>>
>>
>> This has been rather long wait from my side of the pond (moving has
>> taken away quite some time from my side).  But I'll be in a position
>> to begin discussion on arrangements this weekend for patches to be
>> submitted for GCC 4.8.
>>
>> I would be grateful if we could start and maintain discussions on
>> making this happen, and I hope some sort of agreement could be reached
>> by the end of the month.
>>
>
> I would like to give a gentle reminder of this.  Where should I be
> posting the proposed patches to? The frontend and runtime library
> alone would be a few megabytes in size.

Patches should be posted to gcc-patches@gcc.gnu.org - for large
drop-ins (sub-)tarballs are prefered.  I suppose one way would be
to merge GDC to a branch in the GCC SVN repository first.  Note
that gcc-patches has a size limit (not sure how large it was though),
hosting files somewhere and providing links would be another
way of providing them.

Richard.

>
> Regards
>
> --
> Iain Buclaw
>
> *(p < e ? p++ : p) = (c & 0x0f) + '0';

Re: Merging gdc (GNU D Compiler) into gcc

[Iain Buclaw]

On 10 May 2012 10:48, Richard Guenther <richard.guenther@gmail.com> wrote:
> On Thu, May 10, 2012 at 11:37 AM, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
>> On 11 April 2012 15:12, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
>>> On 4 October 2011 08:08, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
>>>> Hi,
>>>>
>>>> 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: https://bitbucket.org/goshawk/gdc
>>>>
>>>
>>>
>>> This has been rather long wait from my side of the pond (moving has
>>> taken away quite some time from my side).  But I'll be in a position
>>> to begin discussion on arrangements this weekend for patches to be
>>> submitted for GCC 4.8.
>>>
>>> I would be grateful if we could start and maintain discussions on
>>> making this happen, and I hope some sort of agreement could be reached
>>> by the end of the month.
>>>
>>
>> I would like to give a gentle reminder of this.  Where should I be
>> posting the proposed patches to? The frontend and runtime library
>> alone would be a few megabytes in size.
>
> Patches should be posted to gcc-patches@gcc.gnu.org - for large
> drop-ins (sub-)tarballs are prefered.  I suppose one way would be
> to merge GDC to a branch in the GCC SVN repository first.  Note
> that gcc-patches has a size limit (not sure how large it was though),
> hosting files somewhere and providing links would be another
> way of providing them.
>
> Richard.
>

Thanks, would it be best to split the frontend, library, and patches
to gcc proper into three parts?

To provide links provisionally, the current development repository is
here: https://github.com/D-Programming-GDC/GDC


-- 
Iain Buclaw

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

Re: Merging gdc (GNU D Compiler) into gcc

[Manuel López-Ibáñez]

On 10 May 2012 11:52, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
>
> Thanks, would it be best to split the frontend, library, and patches
> to gcc proper into three parts?

From observing how other big projects got merged, I think it is better:

1)  If you have anything that can be committed independently of gdc
(like bug-fixes, cleanups, etc.), send those first as individual
self-contained patches. This will reduce the delta. This will also
give you a sense of the stylistic changes reviewers are more likely to
complain about and fix them in your branch before presenting it for
approval.

2) Next, for changes to various parts of GCC that are not independent
of GDC,  isolate changes by subsystem (see MAINTAINERS), then either
produce a patch or, if too large, point how to get a diff of exactly
those parts in a branch. Send it to gcc-patches and CC the relevant
maintainers. This includes also splitting out changes to the shared
build machinery and to the shared testsuite infrastructure.

3) Finally, once all those parts are approved, you will have to
convince one or various global reviewers to go through the rest of the
branch (FE proper, runtime and testcases) and ACK it.

The merge of Go could be a good example to follow:

http://gcc.gnu.org/ml/gcc/2010-10/msg00342.html

It was finally committed here, so it "only" took two months for
someone who is one of the few top-class experts in GCC, with decades
of experience, so be patient and persevere:

http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00274.html

You should probably also read this:

http://gcc.gnu.org/onlinedocs/gccint/Front-End.html

Cheers,

Manuel.

Re: Merging gdc (GNU D Compiler) into gcc

[Florian Weimer]

* Iain Buclaw:

> 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: https://bitbucket.org/goshawk/gdc

Out of curiosity, what has happened to this effort?

Re: Merging gdc (GNU D Compiler) into gcc

[Iain Buclaw]

On 21 July 2012 21:00, Florian Weimer <fw@deneb.enyo.de> wrote:
> * Iain Buclaw:
>
>> 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: https://bitbucket.org/goshawk/gdc
>
> Out of curiosity, what has happened to this effort?

A start has been made on getting it through review process. I am
working through some of the points raised with GDC so all parties are
satisfied.

http://gcc.gnu.org/ml/gcc-patches/2012-06/msg01203.html


-- 
Iain Buclaw

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

Re: Merging gdc (Gnu D Compiler) into gcc

[Joe Buck]

On Tue, Nov 09, 2010 at 05:08:44AM -0800, Jakub Jelinek wrote:
> On Tue, Nov 09, 2010 at 09:36:08AM +0000, Andrew Haley wrote:
> > > The D specific part of gdc is already GPL, it's just copyrighted by
> > > Digital Mars. I understand the copyright must be reassigned to the FSF.
> > > Is it possible to fork the code, and assign copyright of one fork to the
> > > FSF and leave the other copyrighted by Digital Mars?
> > 
> > The FSF generally allows a grant-back: that is, you assign your code
> > to the FSF, which immediately grants you an unlimited licence to do
> > whatever you want with it.
> 
> Just note that if you'll want to merge back from the FSF tree back to your
> forked tree any changes made there by others, those changes will already be
> copyrighted by the FSF and not Digital Mars.

You might be able to get RMS to agree to an alternative arrangement, but
no one but him could approve it.

Re: Merging gdc (Gnu D Compiler) into gcc

[Jakub Jelinek]

On Tue, Nov 09, 2010 at 09:36:08AM +0000, Andrew Haley wrote:
> > The D specific part of gdc is already GPL, it's just copyrighted by
> > Digital Mars. I understand the copyright must be reassigned to the FSF.
> > Is it possible to fork the code, and assign copyright of one fork to the
> > FSF and leave the other copyrighted by Digital Mars?
> 
> The FSF generally allows a grant-back: that is, you assign your code
> to the FSF, which immediately grants you an unlimited licence to do
> whatever you want with it.

Just note that if you'll want to merge back from the FSF tree back to your
forked tree any changes made there by others, those changes will already be
copyrighted by the FSF and not Digital Mars.

	Jakub

Re: Merging gdc (Gnu D Compiler) into gcc

[Andrew Haley]

On 11/08/2010 11:13 PM, Walter Bright wrote:
> 
> 
> Joseph S. Myers wrote:
>> On Mon, 8 Nov 2010, Walter Bright wrote:
>>
>>  
>>> Who do I need to talk to in order to resolve the various licensing
>>> issues so
>>> this becomes possible?
>>>     
>>
>> The FSF, via the Steering Committee, via this list.  The standard
>> assignment and licensing policies are as described in the Mission
>> Statement <http://gcc.gnu.org/gccmission.html>.  Any special
>> arrangement like that for the Go front end (where part providing the
>> GCC interface is assigned to the FSF and maintained in the GCC tree
>> and part that could be used with other back ends is maintained
>> externally with third-party copyright) needs specific approval.  (Note
>> that the Go front end does not yet achieve the level of separation
>> achieved by Ada, for example; there are plenty of uses of GCC's tree
>> interfaces in the gofrontend/ directory that mean portability to other
>> back ends is more theory than reality.)
> 
> The D specific part of gdc is already GPL, it's just copyrighted by
> Digital Mars. I understand the copyright must be reassigned to the FSF.
> Is it possible to fork the code, and assign copyright of one fork to the
> FSF and leave the other copyrighted by Digital Mars?

The FSF generally allows a grant-back: that is, you assign your code
to the FSF, which immediately grants you an unlimited licence to do
whatever you want with it.

Andrew.

Re: Merging gdc (Gnu D Compiler) into gcc

[Walter Bright]

Joseph S. Myers wrote:
> On Mon, 8 Nov 2010, Walter Bright wrote:
>
>   
>> Who do I need to talk to in order to resolve the various licensing issues so
>> this becomes possible?
>>     
>
> The FSF, via the Steering Committee, via this list.  The standard 
> assignment and licensing policies are as described in the Mission 
> Statement <http://gcc.gnu.org/gccmission.html>.  Any special arrangement 
> like that for the Go front end (where part providing the GCC interface is 
> assigned to the FSF and maintained in the GCC tree and part that could be 
> used with other back ends is maintained externally with third-party 
> copyright) needs specific approval.  (Note that the Go front end does not 
> yet achieve the level of separation achieved by Ada, for example; there 
> are plenty of uses of GCC's tree interfaces in the gofrontend/ directory 
> that mean portability to other back ends is more theory than reality.)
>   

The D specific part of gdc is already GPL, it's just copyrighted by
Digital Mars. I understand the copyright must be reassigned to the FSF.
Is it possible to fork the code, and assign copyright of one fork to the
FSF and leave the other copyrighted by Digital Mars?

> In general I'd like to encourage maintainers of separate front ends - not 
> limited to D - to work towards merging them into FSF GCC and maintaining 
> them there; additional front ends help improve the quality of the core 
> language-independent code, and no doubt GNU/Linux distributors would be 
> glad to avoid the complexities of patching out-of-tree front ends into 
> their GCC packages.  Front ends do of course need to pass technical review 
> and do things in the ways that are considered current good practice for 
> front ends instead of being gratuitously different, but when maintainers 
> are ready to follow current good technical and licensing practice I think 
> having them in FSF GCC benefits both the front ends and GCC.
>
>   

Sounds sensible.

Re: Merging gdc (Gnu D Compiler) into gcc

[Joseph S. Myers]

On Mon, 8 Nov 2010, Walter Bright wrote:

> Who do I need to talk to in order to resolve the various licensing issues so
> this becomes possible?

The FSF, via the Steering Committee, via this list.  The standard 
assignment and licensing policies are as described in the Mission 
Statement <http://gcc.gnu.org/gccmission.html>.  Any special arrangement 
like that for the Go front end (where part providing the GCC interface is 
assigned to the FSF and maintained in the GCC tree and part that could be 
used with other back ends is maintained externally with third-party 
copyright) needs specific approval.  (Note that the Go front end does not 
yet achieve the level of separation achieved by Ada, for example; there 
are plenty of uses of GCC's tree interfaces in the gofrontend/ directory 
that mean portability to other back ends is more theory than reality.)

In general I'd like to encourage maintainers of separate front ends - not 
limited to D - to work towards merging them into FSF GCC and maintaining 
them there; additional front ends help improve the quality of the core 
language-independent code, and no doubt GNU/Linux distributors would be 
glad to avoid the complexities of patching out-of-tree front ends into 
their GCC packages.  Front ends do of course need to pass technical review 
and do things in the ways that are considered current good practice for 
front ends instead of being gratuitously different, but when maintainers 
are ready to follow current good technical and licensing practice I think 
having them in FSF GCC benefits both the front ends and GCC.

-- 
Joseph S. Myers
joseph@codesourcery.com

Merging gdc (Gnu D Compiler) into gcc

[Walter Bright]

Who do I need to talk to in order to resolve the various licensing 
issues so this becomes possible?

----
Walter Bright
Digital Mars
http://www.digitalmars.com
free C, C++, D programming language compilers