LTO ICE in D Frontend
Hi,
I'm trying to get to the bottom of a bug when using the D front-end with -flto.
When compiling anything, it always ICEs at in
streamer_get_pickled_tree, at tree-streamer-in.c.
The of it appears to be that the LTO frontend seems to never retrieve
what it is expected to find. But I don't know what could be missing
from the code generation on my side to sort that out.
The following minimal test that yields an ICE.
---
extern(C) int test = void;
I had set a breakpoint at hash_tree and looked at debug_tree output
from an equivalent program in C++, but nothing stands out as wrong
here to me.
Any insight would be helpful.
// D
DECL_NAME:
DECL_CONTEXT: (null_tree)
DECL_SIZE:
constant 32>
DECL_SIZE_UNIT:
constant 4>
VAR_DECL:
unit size
align 32 symtab 0 alias set 0 canonical type 0x765505e8
precision 32 min max
pointer_to_this >
used public static tls-initial-exec SI file test.d line 1 col 0
size unit size
align 32
(mem/c:SI (symbol_ref:DI ("test") [flags 0x2a] ) [0 test+0 S4 A32])>
// C++
DECL_NAME:
local bindings <(nil)>>
DECL_CONTEXT:
DECL_SIZE:
constant 32>
DECL_SIZE_UNIT:
constant 4>
VAR_DECL:
unit size
align 32 symtab 0 alias set 0 canonical type 0x7655a5e8
precision 32 min max
pointer_to_this >
public static SI file test2.cc line 2 col 5 size unit size
align 32 context
(mem/c:SI (symbol_ref:DI ("test") [flags 0x2] ) [0 test+0 S4 A32]) chain >
Re: LTO ICE in D Frontend
On 10 July 2014 07:31, Iain Buclaw wrote: > Hi, > > I'm trying to get to the bottom of a bug when using the D front-end with > -flto. > > When compiling anything, it always ICEs at in > streamer_get_pickled_tree, at tree-streamer-in.c. > > The of it appears to be that the LTO frontend seems to never retrieve > what it is expected to find. But I don't know what could be missing > from the code generation on my side to sort that out. > > > The following minimal test that yields an ICE. > --- > extern(C) int test = void; > In this example, the LTO expects to find an IDENTIFIER_NODE, but retrieves an ERROR_MARK. Regards Iain.
Re: LTO ICE in D Frontend
On 10 July 2014 08:26, Richard Biener wrote: > On July 10, 2014 8:31:54 AM CEST, Iain Buclaw wrote: >>Hi, >> >>I'm trying to get to the bottom of a bug when using the D front-end >>with -flto. >> >>When compiling anything, it always ICEs at in >>streamer_get_pickled_tree, at tree-streamer-in.c. >> >>The of it appears to be that the LTO frontend seems to never retrieve >>what it is expected to find. But I don't know what could be missing >>from the code generation on my side to sort that out. >> >> >>The following minimal test that yields an ICE. >>--- >>extern(C) int test = void; >> >> >>I had set a breakpoint at hash_tree and looked at debug_tree output >>from an equivalent program in C++, but nothing stands out as wrong >>here to me. >> >>Any insight would be helpful. >> >> >>// D >>DECL_NAME: >> >> >>DECL_CONTEXT: (null_tree) > > This should have a translation unit decl here. > > Richard. I've been avoiding doing that for the last few years. Doesn't progress any further the problem though. It looks like the LTO front-end ICE's before it even attempts to read the decl context. Getting an ERROR_MARK when expecting an IDENTIFIER_NODE. Something not right with the DECL_NAME? Regards Iain.
Re: LTO ICE in D Frontend
On 10 July 2014 10:01, Richard Biener wrote: > On Thu, Jul 10, 2014 at 10:51 AM, Iain Buclaw wrote: >> On 10 July 2014 08:26, Richard Biener wrote: >>> On July 10, 2014 8:31:54 AM CEST, Iain Buclaw >>> wrote: >>>>Hi, >>>> >>>>I'm trying to get to the bottom of a bug when using the D front-end >>>>with -flto. >>>> >>>>When compiling anything, it always ICEs at in >>>>streamer_get_pickled_tree, at tree-streamer-in.c. >>>> >>>>The of it appears to be that the LTO frontend seems to never retrieve >>>>what it is expected to find. But I don't know what could be missing >>>>from the code generation on my side to sort that out. >>>> >>>> >>>>The following minimal test that yields an ICE. >>>>--- >>>>extern(C) int test = void; >>>> >>>> >>>>I had set a breakpoint at hash_tree and looked at debug_tree output >>>>from an equivalent program in C++, but nothing stands out as wrong >>>>here to me. >>>> >>>>Any insight would be helpful. >>>> >>>> >>>>// D >>>>DECL_NAME: >>>> >>>> >>>>DECL_CONTEXT: (null_tree) >>> >>> This should have a translation unit decl here. >>> >>> Richard. >> >> >> I've been avoiding doing that for the last few years. Doesn't >> progress any further the problem though. It looks like the LTO >> front-end ICE's before it even attempts to read the decl context. >> >> Getting an ERROR_MARK when expecting an IDENTIFIER_NODE. >> >> Something not right with the DECL_NAME? > > It rather sounds like sth out-of-sync somewhere. Typical fronend > issues are lang-specific tree codes leaking into LTO but that usually > has a different kind of fallout. > > How is the D frontend integrated? Is it done "regularly", that is, > in-tree? It's important that the all-tree.def generated at build time > is consistent when building the D and the lto frontend. > Yep, all-tree.def should be consistent between the two. d/d-tree.def is included in the generated all-tree.def file. In my example though, only core tree codes are used, and I would have thought that they should be unaffected by the language tree codes (that have higher code numbers). Regards Iain
Re: LTO ICE in D Frontend
On 10 July 2014 11:54, Richard Biener wrote: > On Thu, Jul 10, 2014 at 12:52 PM, Richard Biener > wrote: >> On Thu, Jul 10, 2014 at 11:52 AM, Iain Buclaw wrote: >>> On 10 July 2014 10:01, Richard Biener wrote: >>>> On Thu, Jul 10, 2014 at 10:51 AM, Iain Buclaw >>>> wrote: >>>>> On 10 July 2014 08:26, Richard Biener wrote: >>>>>> On July 10, 2014 8:31:54 AM CEST, Iain Buclaw >>>>>> wrote: >>>>>>>Hi, >>>>>>> >>>>>>>I'm trying to get to the bottom of a bug when using the D front-end >>>>>>>with -flto. >>>>>>> >>>>>>>When compiling anything, it always ICEs at in >>>>>>>streamer_get_pickled_tree, at tree-streamer-in.c. >>>>>>> >>>>>>>The of it appears to be that the LTO frontend seems to never retrieve >>>>>>>what it is expected to find. But I don't know what could be missing >>>>>>>from the code generation on my side to sort that out. >>>>>>> >>>>>>> >>>>>>>The following minimal test that yields an ICE. >>>>>>>--- >>>>>>>extern(C) int test = void; >>>>>>> >>>>>>> >>>>>>>I had set a breakpoint at hash_tree and looked at debug_tree output >>>>>>>from an equivalent program in C++, but nothing stands out as wrong >>>>>>>here to me. >>>>>>> >>>>>>>Any insight would be helpful. >>>>>>> >>>>>>> >>>>>>>// D >>>>>>>DECL_NAME: >>>>>>> >>>>>>> >>>>>>>DECL_CONTEXT: (null_tree) >>>>>> >>>>>> This should have a translation unit decl here. >>>>>> >>>>>> Richard. >>>>> >>>>> >>>>> I've been avoiding doing that for the last few years. Doesn't >>>>> progress any further the problem though. It looks like the LTO >>>>> front-end ICE's before it even attempts to read the decl context. >>>>> >>>>> Getting an ERROR_MARK when expecting an IDENTIFIER_NODE. >>>>> >>>>> Something not right with the DECL_NAME? >>>> >>>> It rather sounds like sth out-of-sync somewhere. Typical fronend >>>> issues are lang-specific tree codes leaking into LTO but that usually >>>> has a different kind of fallout. >>>> >>>> How is the D frontend integrated? Is it done "regularly", that is, >>>> in-tree? It's important that the all-tree.def generated at build time >>>> is consistent when building the D and the lto frontend. >>>> >>> >>> Yep, all-tree.def should be consistent between the two. d/d-tree.def >>> is included in the generated all-tree.def file. In my example though, >>> only core tree codes are used, and I would have thought that they >>> should be unaffected by the language tree codes (that have higher code >>> numbers). >> >> Yeah. I have no clue what goes wrong then, you have to debug it :/ >> (the testcase is small, so see where it writes the corresponding >> pieces in tree-streamer-out.c and try to match-up with the LTO read >> side in two parallel gdb sessions) > > Oh, another common source of issues is that the trees the streamer > cache is seeded with in preload_common_nodes is inconsistent > between D and LTO. In fact I bet it is that (you can simply add > some printfs and try to match entries). > I can say that is a first possible. There's a function ran in D's init hook after all common tree's have been built to override the TYPE_NAME's of common trees. Eg: intQI_type_node from 'signed char' to 'byte'. Commenting it out and giving it a try... Iain
Re: LTO ICE in D Frontend
On 10 July 2014 11:54, Richard Biener wrote: > On Thu, Jul 10, 2014 at 12:52 PM, Richard Biener > wrote: >> On Thu, Jul 10, 2014 at 11:52 AM, Iain Buclaw wrote: >>> On 10 July 2014 10:01, Richard Biener wrote: >>>> On Thu, Jul 10, 2014 at 10:51 AM, Iain Buclaw >>>> wrote: >>>>> On 10 July 2014 08:26, Richard Biener wrote: >>>>>> On July 10, 2014 8:31:54 AM CEST, Iain Buclaw >>>>>> wrote: >>>>>>>Hi, >>>>>>> >>>>>>>I'm trying to get to the bottom of a bug when using the D front-end >>>>>>>with -flto. >>>>>>> >>>>>>>When compiling anything, it always ICEs at in >>>>>>>streamer_get_pickled_tree, at tree-streamer-in.c. >>>>>>> >>>>>>>The of it appears to be that the LTO frontend seems to never retrieve >>>>>>>what it is expected to find. But I don't know what could be missing >>>>>>>from the code generation on my side to sort that out. >>>>>>> >>>>>>> >>>>>>>The following minimal test that yields an ICE. >>>>>>>--- >>>>>>>extern(C) int test = void; >>>>>>> >>>>>>> >>>>>>>I had set a breakpoint at hash_tree and looked at debug_tree output >>>>>>>from an equivalent program in C++, but nothing stands out as wrong >>>>>>>here to me. >>>>>>> >>>>>>>Any insight would be helpful. >>>>>>> >>>>>>> >>>>>>>// D >>>>>>>DECL_NAME: >>>>>>> >>>>>>> >>>>>>>DECL_CONTEXT: (null_tree) >>>>>> >>>>>> This should have a translation unit decl here. >>>>>> >>>>>> Richard. >>>>> >>>>> >>>>> I've been avoiding doing that for the last few years. Doesn't >>>>> progress any further the problem though. It looks like the LTO >>>>> front-end ICE's before it even attempts to read the decl context. >>>>> >>>>> Getting an ERROR_MARK when expecting an IDENTIFIER_NODE. >>>>> >>>>> Something not right with the DECL_NAME? >>>> >>>> It rather sounds like sth out-of-sync somewhere. Typical fronend >>>> issues are lang-specific tree codes leaking into LTO but that usually >>>> has a different kind of fallout. >>>> >>>> How is the D frontend integrated? Is it done "regularly", that is, >>>> in-tree? It's important that the all-tree.def generated at build time >>>> is consistent when building the D and the lto frontend. >>>> >>> >>> Yep, all-tree.def should be consistent between the two. d/d-tree.def >>> is included in the generated all-tree.def file. In my example though, >>> only core tree codes are used, and I would have thought that they >>> should be unaffected by the language tree codes (that have higher code >>> numbers). >> >> Yeah. I have no clue what goes wrong then, you have to debug it :/ >> (the testcase is small, so see where it writes the corresponding >> pieces in tree-streamer-out.c and try to match-up with the LTO read >> side in two parallel gdb sessions) > > Oh, another common source of issues is that the trees the streamer > cache is seeded with in preload_common_nodes is inconsistent > between D and LTO. In fact I bet it is that (you can simply add > some printfs and try to match entries). > It seems that I have got it working! Though I must admit it seems by complete accident rather than intent of my doing. There's some old (pre-2007, before I took over) backend initialisation of wint, pid, intmax... all of which are types not used by the D frontend but a necessity to flesh out GCC builtins to the language. I just did some clean-ups (120 odd line deletions) around it and aligned it up with what the LTO frontend does and... it works! Still, no clue how this could affect whether or not the LTO frontend ICE's, but it does. https://github.com/D-Programming-GDC/GDC/commit/28d98308.diff Regards Iain
Re: [GNU Tools Cauldron 2014] libgccjit.so
On 4 August 2014 22:48, Prathamesh Kulkarni wrote: > Hi, >Please find attached my notes on "libgccjit.so - An experimental > JIT library using GCC as backend". I would be grateful if you would > review it for me. > > Thanks, > Prathamesh The library also has bindings to D too, though I don't mind if you keep this information omitted as it is a recent WIP binding I've started a couple weeks back. Other than that, I think that is a good introduction to the project. Regards Iain.
Re: Trying to develop new frontend
On 5 August 2014 15:17, Daniel Neis wrote:
> Hello,
>
> i am trying to develop a GCC frontend using flex and bison as lexer/parser.
>
> i've read several documentation (the list below and also the gccint.info)
>
> * https://github.com/rabishah/Mini-C-Compiler-using-Flex-And-Yacc/
> * http://www.tldp.org/HOWTO/GCC-Frontend-HOWTO.html
> * https://gcc.gnu.org/wiki/WritingANewFrontEnd
> * https://gcc.gnu.org/ml/gcc-patches/2006-06/msg00648.html
> * https://gcc.gnu.org/wiki/FrontEnd/skeleton
> * http://blog.lxgcc.net/wp-content/uploads/2011/03/GCC_frontend.pdf
> * http://cobolforgcc.sourceforge.net/cobol_14.html#SEC96
> * https://gcc.gnu.org/onlinedocs/gccint/Parsing-pass.html#Parsing-pass
>
> but still having some problems to make it work.
>
> the code is on github:
>
> https://github.com/danielneis/gcc-neis-frontend
>
> the project compiles and generates my compiler "neis1". it is a valid
> elf and i can run it with --help and it shows me the help.
>
> I am testing it with a simple .c file like this:
>
> int main() {
> return 0;
> }
>
> ~/bin$ ./gcc -x neis /home/neis/test.c
> /usr/lib/x86_64-linux-gnu/crt1.o: In function `_start':
> /home/aurel32/glibc/glibc-2.19/csu/../sysdeps/x86_64/start.S:118:
> undefined reference to `main'
> collect2: error: ld returned 1 exit status
>
>
> I think I may be missing some part of code generation with generic,
> but could not find any references...
>
> Any thoughts?
>
I couldn't see any reference to cgraph_finalize_function nor
finalize_compilation_unit. So it looks like you are not sending any
code to the backend to be compiled.
This is a nice point of reference for a skeleton front-end.
https://github.com/giuseppe/gccbrainfuck
Regards
Iain
Re: D Language accepted for inclusion in GCC
On 21 June 2017 at 15:44, David Edelsohn wrote: > I am pleased to announce that the GCC Steering Committee has > accepted the D Language front-end and runtime for inclusion in GCC > and appointed Iain Buclaw as maintainer. > > The patches still require approval by a Global Reviewer. > > Please join me in congratulating Iain on his new role. > Please update your listing in the MAINTAINERS file. > > Happy hacking! > David > Thank you. I have no words for how grateful I am of this, and I look forward to the next stage. Iain.
Merging gdc (GNU D Compiler) into 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';
Re: Merging gdc (GNU D Compiler) into gcc
On 4 October 2011 09:41, Andrew Haley 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
On 4 October 2011 15:02, Ian Lance Taylor wrote: > Iain Buclaw writes: > >> I've have received news from Walter Bright that the license of the D >> frontend has been assigned to the FSF. As the current maintainer of >> GDC, I would like to get this moved forward, starting with getting the >> ball rolling. What would need to be done? And what are the processes >> required? (ie: passing the project through to technical review.) >> >> The current home of GDC is here: 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
On 4 October 2011 17:50, Joseph S. Myers 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
On 4 October 2011 20:36, Andrew Pinski wrote: > On Tue, Oct 4, 2011 at 12:30 PM, Iain Buclaw 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
On 5 October 2011 00:10, Ian Lance Taylor wrote: > Iain Buclaw 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
On 4 October 2011 09:41, Andrew Haley 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: GCC talks at the GNU Hackers Meeting?
On 23 June 2013 15:35, Luca Saiu wrote: > Hello people. > > We're organizing the next GNU Hackers Meeting which will take place next > August in Paris, France; see http://www.gnu.org/ghm/2013/paris . We > still have free slots, so I'm starting to contact people a little > more pro-actively. > > Personally speaking, what I *really* would like is a tutorial talk about > writing a GCC frontend -- which is to say, how to interface with the > middle end. But there are a lot of possible topics as well; out of this > list, I think people don't hear enough about what's happening in the > community. > > Would you like to give a talk? > > If you simply want to attend without speaking, you can register as well. > We're trying to do a little outreach so the talks will be open to > everybody, but of course we particularly welcome GNU contributors. > > Regards, > I did a similar such talk at DConf 2013 with my GCC front-end for the D programming language (GDC). Not sure if would be relevant a GCC conference, but I could think about some of the challenges I've faced. :o) In any case, I would be interested in attending this - just to get a better feel of the community, as a definite future goal would be to get the D front-end merged into GCC proper as an officially supported language. Regards, -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: GCC talks at the GNU Hackers Meeting?
On 24 June 2013 17:02, Luca Saiu wrote: > Hello Iain. I'm adding ghm-discuss in Cc. I think we shouldn't follow > up on gcc@ any more at this point. Let's not bother the hardworking > compiler masters :-). > > On 2013-06-24 at 01:15, Iain Buclaw wrote: > >> I did a similar such talk at DConf 2013 with my GCC front-end for the >> D programming language (GDC). Not sure if would be relevant a GCC >> conference, but I could think about some of the challenges I've faced. >> :o) > > I for one would be very interested. > > Well, the conference is about GNU in general, so many people will not be > particularly familiar with GCC internals. I, for example, have some > knowledge about the general architecture but don't actually know the > API, and have never attempted any non-trivial modification to the GCC > source base. Some people will be more familiar than me, others even > less; but I don't think that it's a serious problem if a few talks are > less accessible than others. I like Einstein's phrase "as simple as > possible, but not simpler". If needed we can make a GCC session or an > "advanced" session, and schedule all such talks close together for the > public's sake. > > Your talk could follow Philip's, I suppose, since if I understood > correctly Philips wanted to talk about frontends in general, and you > more specifically about the frontend of D. What do you think, Philip? > We can certainly have both talks, but I think it would be better if we > tried not to say the same things twice. > My talk at Dconf2013 can be bulleted into the following: - What is GDC? - A brief history of porting the D language to GCC. - D language and library support, including current challenges being faced. - Introduction to GCC, in particular an overview of the compilation process from GENERIC down to RTL and how things tie in with the D front end. - Taking advantage of the GCC backend. What features of GCC are leveraged by the D front end (eg: builtin functions, extended assembler) - Future goals and architecture support. >> In any case, I would be interested in attending this - just to get a >> better feel of the community, as a definite future goal would be to >> get the D front-end merged into GCC proper as an officially supported >> language. > > Of course, welcome. I've registered you and added your talk to the > web page. Please register to ghm-discuss at > https://lists.gnu.org/mailman/listinfo/ghm-discuss . > Have registered myself. I'll have to confirm my availability. Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: GCC talks at the GNU Hackers Meeting?
On 24 June 2013 18:38, Luca Saiu wrote: > On 2013-06-24 at 19:14, Iain Buclaw wrote: > >> My talk at Dconf2013 can be bulleted into the following: >> >> - What is GDC? >> - A brief history of porting the D language to GCC. >> - D language and library support, including current challenges being faced. >> - Introduction to GCC, in particular an overview of the compilation >> process from GENERIC down to RTL and how things tie in with the D >> front end. >> - Taking advantage of the GCC backend. What features of GCC are >> leveraged by the D front end (eg: builtin functions, extended >> assembler) >> - Future goals and architecture support. > > Cool for me. If we have Philip's talk as well then part of your fourth > point might become redundant, but it's quite small fraction of the talk. > > Of course you can reuse slides. We all do :-). > As I said, I can rehash some of what was gone over and perhaps focus more on challenges of representing the D language within GCC. (Eg: Delegates, Thunks, TLS symbols and D runtime...) >> Have registered myself. I'll have to confirm my availability. > > Oh, sorry. I'm marking your name as "to be confirmed" then. > No problem mate, I'll let you know as soon as possible. Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: Merging gdc (GNU D Compiler) into gcc
On 4 October 2011 08:08, 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.) > > 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
On 11 April 2012 15:12, Iain Buclaw wrote: > On 4 October 2011 08:08, 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.) >> >> 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
On 10 May 2012 10:48, Richard Guenther wrote: > On Thu, May 10, 2012 at 11:37 AM, Iain Buclaw wrote: >> On 11 April 2012 15:12, Iain Buclaw wrote: >>> On 4 October 2011 08:08, 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.) >>>> >>>> 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-patc...@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
On 21 July 2012 21:00, Florian Weimer 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';
