* Merging gdc (GNU D Compiler) into gcc @ 2011-10-04 7:08 Iain Buclaw 2011-10-04 8:41 ` Andrew Haley ` (5 more replies) 0 siblings, 6 replies; 39+ messages in thread From: Iain Buclaw @ 2011-10-04 7:08 UTC (permalink / raw) To: gcc 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'; ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (GNU D Compiler) into gcc 2011-10-04 7:08 Merging gdc (GNU D Compiler) into gcc Iain Buclaw @ 2011-10-04 8:41 ` Andrew Haley 2011-10-04 18:19 ` Iain Buclaw 2011-10-06 15:15 ` Iain Buclaw 2011-10-04 14:03 ` Ian Lance Taylor ` (4 subsequent siblings) 5 siblings, 2 replies; 39+ messages in thread From: Andrew Haley @ 2011-10-04 8:41 UTC (permalink / raw) To: Iain Buclaw; +Cc: gcc 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (GNU D Compiler) into gcc 2011-10-04 8:41 ` Andrew Haley @ 2011-10-04 18:19 ` Iain Buclaw 2011-10-06 15:15 ` Iain Buclaw 1 sibling, 0 replies; 39+ messages in thread From: Iain Buclaw @ 2011-10-04 18:19 UTC (permalink / raw) To: Andrew Haley; +Cc: gcc 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'; ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (GNU D Compiler) into gcc 2011-10-04 8:41 ` Andrew Haley 2011-10-04 18:19 ` Iain Buclaw @ 2011-10-06 15:15 ` Iain Buclaw 1 sibling, 0 replies; 39+ messages in thread From: Iain Buclaw @ 2011-10-06 15:15 UTC (permalink / raw) To: Andrew Haley; +Cc: venix1, gcc 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'; ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (GNU D Compiler) into gcc 2011-10-04 7:08 Merging gdc (GNU D Compiler) into gcc Iain Buclaw 2011-10-04 8:41 ` Andrew Haley @ 2011-10-04 14:03 ` Ian Lance Taylor 2011-10-04 19:30 ` Iain Buclaw 2011-10-04 16:50 ` Joseph S. Myers ` (3 subsequent siblings) 5 siblings, 1 reply; 39+ messages in thread From: Ian Lance Taylor @ 2011-10-04 14:03 UTC (permalink / raw) To: Iain Buclaw; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (GNU D Compiler) into gcc 2011-10-04 14:03 ` Ian Lance Taylor @ 2011-10-04 19:30 ` Iain Buclaw 2011-10-04 19:37 ` Andrew Pinski ` (2 more replies) 0 siblings, 3 replies; 39+ messages in thread From: Iain Buclaw @ 2011-10-04 19:30 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: gcc 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'; ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (GNU D Compiler) into gcc 2011-10-04 19:30 ` Iain Buclaw @ 2011-10-04 19:37 ` Andrew Pinski 2011-10-04 20:13 ` Iain Buclaw 2011-10-04 21:41 ` David Brown 2011-10-04 20:41 ` Tom Tromey 2011-10-05 0:59 ` Ian Lance Taylor 2 siblings, 2 replies; 39+ messages in thread From: Andrew Pinski @ 2011-10-04 19:37 UTC (permalink / raw) To: Iain Buclaw; +Cc: Ian Lance Taylor, gcc 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (GNU D Compiler) into gcc 2011-10-04 19:37 ` Andrew Pinski @ 2011-10-04 20:13 ` Iain Buclaw 2011-10-04 23:11 ` Ian Lance Taylor 2011-10-04 21:41 ` David Brown 1 sibling, 1 reply; 39+ messages in thread From: Iain Buclaw @ 2011-10-04 20:13 UTC (permalink / raw) To: Andrew Pinski; +Cc: Ian Lance Taylor, gcc 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'; ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (GNU D Compiler) into gcc 2011-10-04 20:13 ` Iain Buclaw @ 2011-10-04 23:11 ` Ian Lance Taylor 0 siblings, 0 replies; 39+ messages in thread From: Ian Lance Taylor @ 2011-10-04 23:11 UTC (permalink / raw) To: Iain Buclaw; +Cc: Andrew Pinski, gcc 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (GNU D Compiler) into gcc 2011-10-04 19:37 ` Andrew Pinski 2011-10-04 20:13 ` Iain Buclaw @ 2011-10-04 21:41 ` David Brown 2011-10-04 21:47 ` David Brown 2011-10-04 22:51 ` Andrew Pinski 1 sibling, 2 replies; 39+ messages in thread From: David Brown @ 2011-10-04 21:41 UTC (permalink / raw) To: Andrew Pinski; +Cc: Iain Buclaw, Ian Lance Taylor, gcc 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (GNU D Compiler) into gcc 2011-10-04 21:41 ` David Brown @ 2011-10-04 21:47 ` David Brown 2011-10-04 22:51 ` Andrew Pinski 1 sibling, 0 replies; 39+ messages in thread From: David Brown @ 2011-10-04 21:47 UTC (permalink / raw) To: gcc; +Cc: Iain Buclaw, Ian Lance Taylor, gcc 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (GNU D Compiler) into gcc 2011-10-04 21:41 ` David Brown 2011-10-04 21:47 ` David Brown @ 2011-10-04 22:51 ` Andrew Pinski 2011-10-05 9:31 ` David Brown 1 sibling, 1 reply; 39+ messages in thread From: Andrew Pinski @ 2011-10-04 22:51 UTC (permalink / raw) To: David Brown; +Cc: Iain Buclaw, Ian Lance Taylor, gcc 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (GNU D Compiler) into gcc 2011-10-04 22:51 ` Andrew Pinski @ 2011-10-05 9:31 ` David Brown 2011-10-05 10:00 ` David Brown 2011-10-05 12:49 ` Andi Kleen 0 siblings, 2 replies; 39+ messages in thread From: David Brown @ 2011-10-05 9:31 UTC (permalink / raw) To: Andrew Pinski; +Cc: David Brown, Iain Buclaw, Ian Lance Taylor, gcc 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (GNU D Compiler) into gcc 2011-10-05 9:31 ` David Brown @ 2011-10-05 10:00 ` David Brown 2011-10-05 12:49 ` Andi Kleen 1 sibling, 0 replies; 39+ messages in thread From: David Brown @ 2011-10-05 10:00 UTC (permalink / raw) To: gcc; +Cc: David Brown, Iain Buclaw, Ian Lance Taylor, gcc 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (GNU D Compiler) into gcc 2011-10-05 9:31 ` David Brown 2011-10-05 10:00 ` David Brown @ 2011-10-05 12:49 ` Andi Kleen 2011-10-05 14:44 ` David Brown 1 sibling, 1 reply; 39+ messages in thread From: Andi Kleen @ 2011-10-05 12:49 UTC (permalink / raw) To: David Brown Cc: Andrew Pinski, David Brown, Iain Buclaw, Ian Lance Taylor, gcc 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (GNU D Compiler) into gcc 2011-10-05 12:49 ` Andi Kleen @ 2011-10-05 14:44 ` David Brown 2011-10-05 14:59 ` David Brown 0 siblings, 1 reply; 39+ messages in thread From: David Brown @ 2011-10-05 14:44 UTC (permalink / raw) To: Andi Kleen; +Cc: Andrew Pinski, David Brown, Iain Buclaw, Ian Lance Taylor, gcc 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 > ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (GNU D Compiler) into gcc 2011-10-05 14:44 ` David Brown @ 2011-10-05 14:59 ` David Brown 0 siblings, 0 replies; 39+ messages in thread From: David Brown @ 2011-10-05 14:59 UTC (permalink / raw) To: gcc; +Cc: Andrew Pinski, David Brown, Iain Buclaw, Ian Lance Taylor, gcc 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 > ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (GNU D Compiler) into gcc 2011-10-04 19:30 ` Iain Buclaw 2011-10-04 19:37 ` Andrew Pinski @ 2011-10-04 20:41 ` Tom Tromey 2011-10-05 0:59 ` Ian Lance Taylor 2 siblings, 0 replies; 39+ messages in thread From: Tom Tromey @ 2011-10-04 20:41 UTC (permalink / raw) To: Iain Buclaw; +Cc: Ian Lance Taylor, gcc >>>>> "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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (GNU D Compiler) into gcc 2011-10-04 19:30 ` Iain Buclaw 2011-10-04 19:37 ` Andrew Pinski 2011-10-04 20:41 ` Tom Tromey @ 2011-10-05 0:59 ` Ian Lance Taylor 2011-10-05 4:14 ` Iain Buclaw 2 siblings, 1 reply; 39+ messages in thread From: Ian Lance Taylor @ 2011-10-05 0:59 UTC (permalink / raw) To: Iain Buclaw; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (GNU D Compiler) into gcc 2011-10-05 0:59 ` Ian Lance Taylor @ 2011-10-05 4:14 ` Iain Buclaw 2011-10-11 14:05 ` Dave Korn 0 siblings, 1 reply; 39+ messages in thread From: Iain Buclaw @ 2011-10-05 4:14 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: gcc 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'; ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (GNU D Compiler) into gcc 2011-10-05 4:14 ` Iain Buclaw @ 2011-10-11 14:05 ` Dave Korn 0 siblings, 0 replies; 39+ messages in thread From: Dave Korn @ 2011-10-11 14:05 UTC (permalink / raw) To: Iain Buclaw; +Cc: Ian Lance Taylor, gcc 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (GNU D Compiler) into gcc 2011-10-04 7:08 Merging gdc (GNU D Compiler) into gcc Iain Buclaw 2011-10-04 8:41 ` Andrew Haley 2011-10-04 14:03 ` Ian Lance Taylor @ 2011-10-04 16:50 ` Joseph S. Myers 2011-10-04 19:45 ` Iain Buclaw 2011-10-06 8:31 ` Walter Bright ` (2 subsequent siblings) 5 siblings, 1 reply; 39+ messages in thread From: Joseph S. Myers @ 2011-10-04 16:50 UTC (permalink / raw) To: Iain Buclaw; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (GNU D Compiler) into gcc 2011-10-04 16:50 ` Joseph S. Myers @ 2011-10-04 19:45 ` Iain Buclaw 2011-10-04 19:56 ` Joseph S. Myers 0 siblings, 1 reply; 39+ messages in thread From: Iain Buclaw @ 2011-10-04 19:45 UTC (permalink / raw) To: Joseph S. Myers; +Cc: gcc 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'; ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (GNU D Compiler) into gcc 2011-10-04 19:45 ` Iain Buclaw @ 2011-10-04 19:56 ` Joseph S. Myers 0 siblings, 0 replies; 39+ messages in thread From: Joseph S. Myers @ 2011-10-04 19:56 UTC (permalink / raw) To: Iain Buclaw; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (GNU D Compiler) into gcc 2011-10-04 7:08 Merging gdc (GNU D Compiler) into gcc Iain Buclaw ` (2 preceding siblings ...) 2011-10-04 16:50 ` Joseph S. Myers @ 2011-10-06 8:31 ` Walter Bright 2012-04-11 14:12 ` Iain Buclaw 2012-07-21 20:00 ` Florian Weimer 5 siblings, 0 replies; 39+ messages in thread From: Walter Bright @ 2011-10-06 8:31 UTC (permalink / raw) To: gcc 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! ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (GNU D Compiler) into gcc 2011-10-04 7:08 Merging gdc (GNU D Compiler) into gcc Iain Buclaw ` (3 preceding siblings ...) 2011-10-06 8:31 ` Walter Bright @ 2012-04-11 14:12 ` Iain Buclaw 2012-04-13 23:01 ` Dave Korn 2012-05-10 9:37 ` Iain Buclaw 2012-07-21 20:00 ` Florian Weimer 5 siblings, 2 replies; 39+ messages in thread From: Iain Buclaw @ 2012-04-11 14:12 UTC (permalink / raw) To: gcc 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'; ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (GNU D Compiler) into gcc 2012-04-11 14:12 ` Iain Buclaw @ 2012-04-13 23:01 ` Dave Korn 2012-05-10 9:37 ` Iain Buclaw 1 sibling, 0 replies; 39+ messages in thread From: Dave Korn @ 2012-04-13 23:01 UTC (permalink / raw) To: Iain Buclaw; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (GNU D Compiler) into gcc 2012-04-11 14:12 ` Iain Buclaw 2012-04-13 23:01 ` Dave Korn @ 2012-05-10 9:37 ` Iain Buclaw 2012-05-10 9:48 ` Richard Guenther 1 sibling, 1 reply; 39+ messages in thread From: Iain Buclaw @ 2012-05-10 9:37 UTC (permalink / raw) To: gcc 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'; ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (GNU D Compiler) into gcc 2012-05-10 9:37 ` Iain Buclaw @ 2012-05-10 9:48 ` Richard Guenther 2012-05-10 9:53 ` Iain Buclaw 0 siblings, 1 reply; 39+ messages in thread From: Richard Guenther @ 2012-05-10 9:48 UTC (permalink / raw) To: Iain Buclaw; +Cc: gcc 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'; ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (GNU D Compiler) into gcc 2012-05-10 9:48 ` Richard Guenther @ 2012-05-10 9:53 ` Iain Buclaw 2012-05-10 11:51 ` Manuel López-Ibáñez 0 siblings, 1 reply; 39+ messages in thread From: Iain Buclaw @ 2012-05-10 9:53 UTC (permalink / raw) To: Richard Guenther; +Cc: gcc 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'; ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (GNU D Compiler) into gcc 2012-05-10 9:53 ` Iain Buclaw @ 2012-05-10 11:51 ` Manuel López-Ibáñez 0 siblings, 0 replies; 39+ messages in thread From: Manuel López-Ibáñez @ 2012-05-10 11:51 UTC (permalink / raw) To: Iain Buclaw; +Cc: Richard Guenther, gcc 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (GNU D Compiler) into gcc 2011-10-04 7:08 Merging gdc (GNU D Compiler) into gcc Iain Buclaw ` (4 preceding siblings ...) 2012-04-11 14:12 ` Iain Buclaw @ 2012-07-21 20:00 ` Florian Weimer 2012-07-24 20:37 ` Iain Buclaw 5 siblings, 1 reply; 39+ messages in thread From: Florian Weimer @ 2012-07-21 20:00 UTC (permalink / raw) To: Iain Buclaw; +Cc: gcc * 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? ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (GNU D Compiler) into gcc 2012-07-21 20:00 ` Florian Weimer @ 2012-07-24 20:37 ` Iain Buclaw 0 siblings, 0 replies; 39+ messages in thread From: Iain Buclaw @ 2012-07-24 20:37 UTC (permalink / raw) To: Florian Weimer; +Cc: gcc 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'; ^ permalink raw reply [flat|nested] 39+ messages in thread
* Merging gdc (Gnu D Compiler) into gcc @ 2010-11-08 23:13 Walter Bright 2010-11-09 1:14 ` Joseph S. Myers 0 siblings, 1 reply; 39+ messages in thread From: Walter Bright @ 2010-11-08 23:13 UTC (permalink / raw) To: gcc 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (Gnu D Compiler) into gcc 2010-11-08 23:13 Merging gdc (Gnu " Walter Bright @ 2010-11-09 1:14 ` Joseph S. Myers 2010-11-09 7:22 ` Walter Bright 0 siblings, 1 reply; 39+ messages in thread From: Joseph S. Myers @ 2010-11-09 1:14 UTC (permalink / raw) To: Walter Bright; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (Gnu D Compiler) into gcc 2010-11-09 1:14 ` Joseph S. Myers @ 2010-11-09 7:22 ` Walter Bright 2010-11-09 13:09 ` Andrew Haley 0 siblings, 1 reply; 39+ messages in thread From: Walter Bright @ 2010-11-09 7:22 UTC (permalink / raw) To: gcc 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (Gnu D Compiler) into gcc 2010-11-09 7:22 ` Walter Bright @ 2010-11-09 13:09 ` Andrew Haley 2010-11-09 13:57 ` Jakub Jelinek 0 siblings, 1 reply; 39+ messages in thread From: Andrew Haley @ 2010-11-09 13:09 UTC (permalink / raw) To: Walter Bright; +Cc: gcc 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (Gnu D Compiler) into gcc 2010-11-09 13:09 ` Andrew Haley @ 2010-11-09 13:57 ` Jakub Jelinek 2010-11-09 16:43 ` Joe Buck 0 siblings, 1 reply; 39+ messages in thread From: Jakub Jelinek @ 2010-11-09 13:57 UTC (permalink / raw) To: Andrew Haley; +Cc: Walter Bright, gcc 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Merging gdc (Gnu D Compiler) into gcc 2010-11-09 13:57 ` Jakub Jelinek @ 2010-11-09 16:43 ` Joe Buck 0 siblings, 0 replies; 39+ messages in thread From: Joe Buck @ 2010-11-09 16:43 UTC (permalink / raw) To: Jakub Jelinek; +Cc: Andrew Haley, Walter Bright, gcc 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
end of thread, other threads:[~2012-07-24 20:37 UTC | newest] Thread overview: 39+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-10-04 7:08 Merging gdc (GNU D Compiler) into gcc Iain Buclaw 2011-10-04 8:41 ` Andrew Haley 2011-10-04 18:19 ` Iain Buclaw 2011-10-06 15:15 ` Iain Buclaw 2011-10-04 14:03 ` Ian Lance Taylor 2011-10-04 19:30 ` Iain Buclaw 2011-10-04 19:37 ` Andrew Pinski 2011-10-04 20:13 ` Iain Buclaw 2011-10-04 23:11 ` Ian Lance Taylor 2011-10-04 21:41 ` David Brown 2011-10-04 21:47 ` David Brown 2011-10-04 22:51 ` Andrew Pinski 2011-10-05 9:31 ` David Brown 2011-10-05 10:00 ` David Brown 2011-10-05 12:49 ` Andi Kleen 2011-10-05 14:44 ` David Brown 2011-10-05 14:59 ` David Brown 2011-10-04 20:41 ` Tom Tromey 2011-10-05 0:59 ` Ian Lance Taylor 2011-10-05 4:14 ` Iain Buclaw 2011-10-11 14:05 ` Dave Korn 2011-10-04 16:50 ` Joseph S. Myers 2011-10-04 19:45 ` Iain Buclaw 2011-10-04 19:56 ` Joseph S. Myers 2011-10-06 8:31 ` Walter Bright 2012-04-11 14:12 ` Iain Buclaw 2012-04-13 23:01 ` Dave Korn 2012-05-10 9:37 ` Iain Buclaw 2012-05-10 9:48 ` Richard Guenther 2012-05-10 9:53 ` Iain Buclaw 2012-05-10 11:51 ` Manuel López-Ibáñez 2012-07-21 20:00 ` Florian Weimer 2012-07-24 20:37 ` Iain Buclaw -- strict thread matches above, loose matches on Subject: below -- 2010-11-08 23:13 Merging gdc (Gnu " Walter Bright 2010-11-09 1:14 ` Joseph S. Myers 2010-11-09 7:22 ` Walter Bright 2010-11-09 13:09 ` Andrew Haley 2010-11-09 13:57 ` Jakub Jelinek 2010-11-09 16:43 ` Joe Buck
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).