Re: gcc : c++11 : full support : eta?
Gerald Pfeifer wrote, On Monday 18 February 2013 02:17 AM: On Thu, 24 Jan 2013, Richard Biener wrote: There are technical details of the maintaining part - like would the material reside in SVN? Or in the CVS where we keep our webpages? Or somewhere else public (github?)? Would we want to have an official maintainer and use the usual patch / review / approve mechanism for changes? Which raises the question of the format the courseware is in? Gerald? David? Whatever works for Uday and team, I'd say. With a strong recommendation to go for SVN since that is our primary tool for version control (and a stronger recommendation against CVS which I'd really love to migrate also the web pages away from). I am absolutely fine with SVN because that's what I use :-) However, we need some clarity on exactly what will go in SVN. We will have things like: * Text files such as html files (absolutely fine with SVN). * PDF slides (unsuitable for SVN because they are binary files). I don't mind uploading the LaTeX sources and associated Makefiles for creating pdf.However, we will need to test them out on a few machines that I have never touched to make sure that they don't depend on some local installations that I have stopped noticing. These slides do have some .epsi images that will also have to be added to the SVN repo. * Videos of lectures. I guess these are best kept in the form of links to our servers because we have high definition recordings (we will also make more space efficient videos) so a streaming option is best. So the most critical question is: Do we want to give LaTeX sources of slides or only the PDF files only. I am okay with both the options. Yeah, I know - the obvious link from the gcc.gnu.org page to click for a newcomer is 'contribute', but that page is awkward enough to scare off a possible contributor ;) True. Any ideas/suggestions? Happy to make changes... I'll try to come up with some concrete suggestions on how they can be reorganized. Uday.
Re: gcc : c++11 : full support : eta?
On Thu, 24 Jan 2013, Richard Biener wrote: There are technical details of the maintaining part - like would the material reside in SVN? Or in the CVS where we keep our webpages? Or somewhere else public (github?)? Would we want to have an official maintainer and use the usual patch / review / approve mechanism for changes? Which raises the question of the format the courseware is in? Gerald? David? Whatever works for Uday and team, I'd say. With a strong recommendation to go for SVN since that is our primary tool for version control (and a stronger recommendation against CVS which I'd really love to migrate also the web pages away from). Yeah, I know - the obvious link from the gcc.gnu.org page to click for a newcomer is 'contribute', but that page is awkward enough to scare off a possible contributor ;) True. Any ideas/suggestions? Happy to make changes... Gerald
Re: gcc : c++11 : full support : eta?
On 02/16/2013 01:30 AM, Franz Fehringer wrote: Will gcc 4.8 contain the stdatomic.h header (i am a little confused about it, is it a standard header?)? It's part of the C11 standard, not C++11. C11 atomics will not be supported in 4.8, but should be in 4.9. Jason
Re: gcc : c++11 : full support : eta?
On 01/28/2013 02:24 PM, Jason Merrill wrote: On 01/23/2013 01:48 AM, Franz Fehringer wrote: What does this mean for the Concurrency section, it has 8xNo at the moment? I need to go back over that section, but I think it's just inaccurate. I've now updated the page. Jason
Re: gcc : c++11 : full support : eta?
2013/2/16 Franz Fehringer: Thanks, looking much better now. i am a little confused about it, is it a standard header? Hi, Yes: If the macro constant __STDC_NO_ATOMICS__(C11) is defined by the compiler, the header stdatomic.h, the keyword _Atomic, and all of the names listed here are not provided. http://en.cppreference.com/w/c/atomic -- Regards, niXman ___ Dual-target(32 64-bit) MinGW compilers for 32 and 64-bit Windows: http://sourceforge.net/projects/mingwbuilds/ ___ Another online IDE: http://liveworkspace.org/
Re: gcc : c++11 : full support : eta?
On Feb 8, 2013, at 8:24 AM, Jeff Law l...@redhat.com wrote: I'm not quite sure that this clean split is possible, even after making amends for template instantiation. It's great for syntax-driven tools, but once you move beyond that, you tend to ignore stuff like destructors (or the cleanup attribute), life-times of temporaries etc., things which are just not visible in an AST. You have to reimplement many program analysis algorithms typically part of compiler optimizers, after lowering the AST to a less elaborate intermediate representation (a step which requires a fair amount of knowledge about the language in question). There's always going to be some things that are best done with the raw ASTs and others which are best done when we've got a lowered IL, CFG, SSA graph, etc. The big question is how well can you go from the output of clang into a lower level IR where you can do in depth analysis and how much you allow optimizers to perturb the results of the analysis. One could argue that clang - gimple would be a useful translator to allow the nice things from the clang front-end, but also still allow the more in-depth analysis done by our tree-ssa code. FWIW, the Clang static analyzer uses just such a representation: it is a CFG formed out of AST nodes. -Chris
Re: gcc : c++11 : full support : eta?
On 01/24/2013 08:55 PM, Diego Novillo wrote: I do see, however, a few areas where Clang/LLVM have gone that I do not think GCC is currently thinking of entering: toolability (for the lack of a better term). Clang's design follows a different path than g++. It's not just a code generating parser, it is a pure parser that also generates code. The difference makes it suitable for any kind of tool that needs to understand C++: static analyzers, code re-formatters, syntax highlighters, and other similar tools. Additionally, it is designed as a library, so it can be embedded into applications. I'm not quite sure that this clean split is possible, even after making amends for template instantiation. It's great for syntax-driven tools, but once you move beyond that, you tend to ignore stuff like destructors (or the cleanup attribute), life-times of temporaries etc., things which are just not visible in an AST. You have to reimplement many program analysis algorithms typically part of compiler optimizers, after lowering the AST to a less elaborate intermediate representation (a step which requires a fair amount of knowledge about the language in question). -- Florian Weimer / Red Hat Product Security Team
Re: gcc : c++11 : full support : eta?
On 02/08/2013 09:15 AM, Florian Weimer wrote: On 01/24/2013 08:55 PM, Diego Novillo wrote: I do see, however, a few areas where Clang/LLVM have gone that I do not think GCC is currently thinking of entering: toolability (for the lack of a better term). Clang's design follows a different path than g++. It's not just a code generating parser, it is a pure parser that also generates code. The difference makes it suitable for any kind of tool that needs to understand C++: static analyzers, code re-formatters, syntax highlighters, and other similar tools. Additionally, it is designed as a library, so it can be embedded into applications. I'm not quite sure that this clean split is possible, even after making amends for template instantiation. It's great for syntax-driven tools, but once you move beyond that, you tend to ignore stuff like destructors (or the cleanup attribute), life-times of temporaries etc., things which are just not visible in an AST. You have to reimplement many program analysis algorithms typically part of compiler optimizers, after lowering the AST to a less elaborate intermediate representation (a step which requires a fair amount of knowledge about the language in question). There's always going to be some things that are best done with the raw ASTs and others which are best done when we've got a lowered IL, CFG, SSA graph, etc. The big question is how well can you go from the output of clang into a lower level IR where you can do in depth analysis and how much you allow optimizers to perturb the results of the analysis. One could argue that clang - gimple would be a useful translator to allow the nice things from the clang front-end, but also still allow the more in-depth analysis done by our tree-ssa code. Jeff
Re: gcc : c++11 : full support : eta?
On 01/23/2013 01:48 AM, Franz Fehringer wrote: What does this mean for the Concurrency section, it has 8xNo at the moment? I need to go back over that section, but I think it's just inaccurate. Jason
Re: gcc : c++11 : full support : eta?
Il 25/01/2013 08:24, Uday P. Khedker ha scritto: Exactly. We have been using our training program since 2007 (and have been incrementally refining it on a continuously). Our experience has been that it has brought down the ramp up period of novices to a couple of week. A couple of weeks is really unbelievable. Congratulations! Paolo
Re: gcc : c++11 : full support : eta?
Paolo Bonzini wrote, On Friday 25 January 2013 05:38 PM: Il 25/01/2013 08:24, Uday P. Khedker ha scritto: Exactly. We have been using our training program since 2007 (and have been incrementally refining it on a continuously). Our experience has been that it has brought down the ramp up period of novices to a couple of week. A couple of weeks is really unbelievable. Congratulations! Thanks! Yes, it does look incredible but the material at http://www.cse.iitb.ac.in/grc/gcc-workshop-12/ was developed over four years and has been continuously refined for five years (so it is a nine years' effort on part of my group). Some of my most brilliant minds toiled hard to ask simple questions eg. what is the _minimal_ machine description for GCC, how can we incrementally refine machine descriptions, can machine descriptions be any simpler, what are the programming assignments that one should do to be sufficiently independent (and ask meaningful questions on the gcc mailing list!), what is the overall structure of the compiler generator, what is the overall structure of the generated compiler, what is the retargetability mechanism (i.e. what is the relationship of the md file with the generated compiler) etc. We had to find the right balance between details and concepts and that is what took most of the time. We did not want information to be the focus. We wanted the understanding of the learner to be the main focus. The training program is called Essential Abstractions in GCC; all of which are summarized in http://www.cse.iitb.ac.in/grc/gcc-workshop-12/downloads/slides/gccw12-essential-abstractions.pdf. Needless to say, there is a lot of scope for improvement :-) I would be happy if this becomes acceptable as the first course in GCC. A side benefit of doing so is that then it will be easier for me to pick the minds of the developers for improving it :-) Uday. P.S. : May be I am belabouring the point, but for me there is a lot of difference between the following two responses: (a) You are free to develop any training material and hook it up via gcc wiki. (b) Let us adopt this as the first course and we all will give inputs on how it can be refined and made better. Response (a) is a tautology but it also limits the reach and the effectiveness of the course. It also contributes to confusing a newcomer. -- -- Dr. Uday Khedker Professor Department of Computer Science Engg. IIT Bombay, Powai, Mumbai 400 076, India. Email : u...@cse.iitb.ac.in Homepage: http://www.cse.iitb.ac.in/~uday Phone : Office -91 (22) 2572 2545 x 7717, 91 (22) 2576 7717 (Direct) Res. -91 (22) 2572 2545 x 8717, 91 (22) 2576 8717 (Direct)
Re: gcc : c++11 : full support : eta?
On Thu, Jan 24, 2013 at 1:59 PM, Jeff Law l...@redhat.com wrote: On 01/24/2013 12:55 PM, Diego Novillo wrote: I do see, however, a few areas where Clang/LLVM have gone that I do not think GCC is currently thinking of entering: toolability (for the lack of a better term). Clang's design follows a different path than g++. It's not just a code generating parser, it is a pure parser that also generates code. The difference makes it suitable for any kind of tool that needs to understand C++: static analyzers, code re-formatters, syntax highlighters, and other similar tools. Additionally, it is designed as a library, so it can be embedded into applications. Yup. We kicked stuff in this area around as well as we were discussing the problems early folding presents. In an ideal world, the G++ parser would turn into something that can be used not just for G++, but as a library for other tools that need to parse C++ code (doxygen, gdb and I'm sure there's others). First all of I should confess that I have had long interest in having a modular g++ parser in the sense that I would like the ability to retarget it to other purposes that we cannot realistically expect a single simple C++ compiler to satisfy simultaneously. However parsing C++ is a very tricky. Depending on the level of fidelity to the C++ spec, parsing involves template instantiation, which itself may involve overload resolution, etc. So when we are talking about a C++ parser module, this means we need a much better typed AST to represent the semantics graph before gimplification. -- Gaby
Re: gcc : c++11 : full support : eta?
I have been following this discussion for quite a while now, guess it's the right time to introduce myself as one of the newcomers. I had attended the Abstractions in GCC workshop 2012 by Prof. Uday and his team. It definitely helped me kick start with understanding of GCC and got me interested; so much so that I chose GCC as the framework to implement a global analysis algorithm as my final year project (I am a CSE Undergraduate student in India). Up to now, I have tried to make my foundations strong by learning essential theory by taking courses in Compiler Construction Compiler Design involving study of optimization techniques and other basics. In the next 2-3 months I plan to study the source code more rigorously and implement the analysis algorithm. I certainly agree about lack of direction and documentation, I found even the Internals document incomplete at many points in satisfying my curiosity about certain questions related to GCC. Good to see there is an effort to change the state of affairs. I would like to volunteer for any kind of contribution I can make in this effort, and I think, as a newcomer, I will have a slightly different perspective of things that might help in solving this problem. Thanks -- Kartik http://k4rtik.wordpress.com/
Re: gcc : c++11 : full support : eta?
I am keeping a diary of sorts about what I think GCC is and how that changes, how it does things, so forth. Please keep one too! Alec
Re: Long term viability of GCC (was Re: gcc : c++11 : full support : eta?)
On 01/23/2013 07:38 PM, Diego Novillo wrote: Evolving this codebase is largely a thankless and difficult job. It's technically interesting to me, but I know I can only do so much. It's also worth pointing out that historically it's been very difficult to persuade people to fund this. Many companies want back- ends for their chosen processor, but not many want to pay to reorganize GCC itself, which would benefit every user. Andrew.
Re: gcc : c++11 : full support : eta?
On Thursday 24 January 2013 02:32 AM, Diego Novillo wrote: On Wed, Jan 23, 2013 at 2:40 PM, Uday Khedker u...@cse.iitb.ac.in wrote: This is very different from putting it as one among so many other things on the wiki. Look at it from the view point of a newcomer. There are so many OK, then. Reorganize GettingStarted to make it prominent and advertise it. Move the other tutorials down below. Make it so a newcomer is not presented with an endless array of links. If something better comes along, then you duke it out with them. Simple as that. Will do that. So far I was hesitant in touching links created by others. I wasn't sure if taking responsibility automatically grants me the right to change what others have put up and that is why I was seeking support of the steering committee. Uday.
Re: gcc : c++11 : full support : eta?
On 01/24/2013 09:39 AM, Uday Khedker wrote: I wasn't sure if taking responsibility automatically grants me the right to change what others have put up and that is why I was seeking support of the steering committee. It's not appropriate to involve the every decision, especially when it's not controversial. GCC operates mostly by consensus, and the SC goes to great lengths to avoid having to make decisions! :-) Andrew.
Re: gcc : c++11 : full support : eta?
On Thu, Jan 24, 2013 at 2:44 PM, Alec Teal a.t...@warwick.ac.uk wrote: I am keeping a diary of sorts about what I think GCC is and how that changes, how it does things, so forth. Please keep one too! Thanks for the suggestion. Will do that from now on. -- Kartik http://k4rtik.wordpress.com/
Re: gcc : c++11 : full support : eta?
On Wed, Jan 23, 2013 at 8:40 PM, Uday Khedker u...@cse.iitb.ac.in wrote: On Thursday 24 January 2013 12:35 AM, Richard Biener wrote: Uday Khedker u...@cse.iitb.ac.in wrote: I have been trying to do my stuff for a few years. We conduct a programme called Essential Abstractions in GCC which is aimed at taking a novice to a level from where she can do independent experimentation with GCC internals. I put together a bunch of teaching assistants (about 15 of them) for about 60 participants. Carefully designed programming assignments are an integral part of the training. The program ends with us summarizing the essential abstractions in 17 or 18 pictures with the hope that if one can understand the concepts represented by the pictures, one can walk the maze of the GCC code. You can find the details of the latest offering at http://www.cse.iitb.ac.in/grc/gcc-workshop-12/. I would like to take this training program to the next level but so long it remains my personal baby, my funding agency does not feel that I have accomplished much because they feel that if my program has any merit, the GCC community would adopt it :-( Can you hint at what they would consider adopting it? I suppose it is not simply linking to it from the wiki or the website? I know it sounds awkward but a government funding agency has its own notion of what is official and what is not official. In their eyes, the GCC steering committee, the maintainers appointed by the steering committee etc. are official. All others are hobbyists :-) But on a serious note, it would be great to view the course material as more than documentation. The way there are official manuals and official code available on the gcc website (I can't have my own manual and call it GCC manual, or put up my code and call it GCC code), it would be good to have an official courseware. Anything I would consider official courseware would have to be contributed to and maintained by the community (of which you can play the main part of course). Now I don't know whether it is wise to try to ask the FSF if it wants to have it (probably not ...). I as member of the community would welcome such contribution and be happy to occasionally review the material for it's up-to-date-ness. There are technical details of the maintaining part - like would the material reside in SVN? Or in the CVS where we keep our webpages? Or somewhere else public (github?)? Would we want to have an official maintainer and use the usual patch / review / approve mechanism for changes? Which raises the question of the format the courseware is in? Gerald? David? This is very different from putting it as one among so many other things on the wiki. Look at it from the view point of a newcomer. There are so many links and so many documents on the wiki that one does not even know where to begin from. Can we have ONE course for newcomers (of course refined based on the inputs from the developers) which the developers think represent their knowledge well enough for the newcomers? I don't mean to remove other material. We should have as much variety as possible but let there be one agreed upon starting point. After achieving some maturity, a person is not a newcomer and would be able to extract far more out of the other options that exist anyway. Yeah, I know - the obvious link from the gcc.gnu.org page to click for a newcomer is 'contribute', but that page is awkward enough to scare off a possible contributor ;) Improving that front-door would be a good start (and this is an official part and not the wiki). Thanks, Richard. I will be very happy to take the responsibility of taking inputs and keep refining my material until we have something that we all feel is better than anything that we have had so far. That is what I mean by adoption of the training program. While I may not like what funding agency says, I do see a valid point in their expectations: They ask me How have you influenced the GCC movement?. They are smart enough to know the difference between what I have done and whether the GCC community cares about it or not :-) Uday.
Re: gcc : c++11 : full support : eta?
On Thursday 24 January 2013 03:17 PM, Andrew Haley wrote: On 01/24/2013 09:39 AM, Uday Khedker wrote: I wasn't sure if taking responsibility automatically grants me the right to change what others have put up and that is why I was seeking support of the steering committee. It's not appropriate to involve the every decision, especially when it's not controversial. GCC operates mostly by consensus, and the SC goes to great lengths to avoid having to make decisions! :-) Andrew. Thanks for the assurance :-) Uday.
Re: gcc : c++11 : full support : eta?
On Wed, Jan 23, 2013 at 2:40 PM, Uday Khedker u...@cse.iitb.ac.in wrote: But on a serious note, it would be great to view the course material as more than documentation. The way there are official manuals and official code available on the gcc website (I can't have my own manual and call it GCC manual, or put up my code and call it GCC code), it would be good to have an official courseware. This is very different from putting it as one among so many other things on the wiki. Look at it from the view point of a newcomer. There are so many links and so many documents on the wiki that one does not even know where to begin from. Can we have ONE course for newcomers (of course refined based on the inputs from the developers) which the developers think represent their knowledge well enough for the newcomers? I don't mean to remove other material. We should have as much variety as possible but let there be one agreed upon starting point. After achieving some maturity, a person is not a newcomer and would be able to extract far more out of the other options that exist anyway. I will be very happy to take the responsibility of taking inputs and keep refining my material until we have something that we all feel is better than anything that we have had so far. That is what I mean by adoption of the training program. 1) Check it in to svn 2) Host your material on gnu.org 3) Profit!!
Re: gcc : c++11 : full support : eta?
Richard Biener wrote, On Thursday 24 January 2013 05:38 PM: Anything I would consider official courseware would have to be contributed to and maintained by the community (of which you can play the main part of course). Now I don't know whether it is wise to try to ask the FSF if it wants to have it (probably not ...). I as member of the community would welcome such contribution and be happy to occasionally review the material for it's up-to-date-ness. This is exactly what want to happen. There are technical details of the maintaining part - like would the material reside in SVN? Or in the CVS where we keep our webpages? Or somewhere else public (github?)? Would we want to have an official maintainer and use the usual patch / review / approve mechanism for changes? Which raises the question of the format the courseware is in? Gerald? David? By default, we make the slides available in pdf format but we can also upload the LaTeX and Beamer source if so desired. To keep the matter simple in the beginning, it may also be possible to basically reorganize web pages and divide the material in two parts. The existing material stays where it is with appropriate links and the proposed course material also stays on my server with appropriate links in the web pages. I would be happy to play the role of the maintainer regardless which approach the community decides to adopt. This is very different from putting it as one among so many other things on the wiki. Look at it from the view point of a newcomer. There are so many links and so many documents on the wiki that one does not even know where to begin from. Can we have ONE course for newcomers (of course refined based on the inputs from the developers) which the developers think represent their knowledge well enough for the newcomers? I don't mean to remove other material. We should have as much variety as possible but let there be one agreed upon starting point. After achieving some maturity, a person is not a newcomer and would be able to extract far more out of the other options that exist anyway. Yeah, I know - the obvious link from the gcc.gnu.org page to click for a newcomer is 'contribute', but that page is awkward enough to scare off a possible contributor ;) Improving that front-door would be a good start (and this is an official part and not the wiki). Yes and it is from this view point that I had been seeking SC support. Thanks and regards, Uday.
Re: gcc : c++11 : full support : eta?
On Jan 23, 2013, Aldy Hernandez al...@redhat.com wrote: an internal training program Jeff Law devised over a decade ago (*) [Before anybody asks, the training program is probably no longer relevant. So no fair bugging Jeff about it :)]. Yeah. It was focused on the RTL/md part of GCC, with a few simple assignments that amounted to implementing changes in the mn10300-elf port. That was before AM33/2.0 came up; before gimple and SSA, long before tuples and mode iterators. GCC was a very different beast then. The course made me more of an RTL person, which still makes me hope this tree-based stuff a fad and that some day we'll get back to our senses and do SSA in RTL ;-) -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: gcc : c++11 : full support : eta?
On 01/24/2013 10:23 AM, Alexandre Oliva wrote: On Jan 23, 2013, Aldy Hernandez al...@redhat.com wrote: an internal training program Jeff Law devised over a decade ago (*) [Before anybody asks, the training program is probably no longer relevant. So no fair bugging Jeff about it :)]. Yeah. It was focused on the RTL/md part of GCC, with a few simple assignments that amounted to implementing changes in the mn10300-elf port. That was before AM33/2.0 came up; before gimple and SSA, long before tuples and mode iterators. GCC was a very different beast then. The course made me more of an RTL person, which still makes me hope this tree-based stuff a fad and that some day we'll get back to our senses and do SSA in RTL ;-) And the thing to remember about that training program is that it was geared strictly towards backend porting. ie, new version of the frob chip comes out with some new instructions, we need to support them. That was a significant component of Cygnus's business back then. As Alex notes, GCC today is dramatically different and hacking new instructions into existing backends isn't nearly as important as it was 10+ years ago. Training around GCC's implementation of SSA, how GCC's optimization pipeline works, plugins, the propagation engine would be far more interesting and useful. When we made the change from RTL centric to gimple, one of the goals was to make GCC more approachable. I would argue to some degree that was successful, but not nearly as much as I'd hoped. Of course that was over 10 years ago and we're at another point where some significant architectural changes to GCC are needed. Google has kicked some stuff around and Red Hat is kicking stuff around toward that goal. I believe the ultimate focus will be on improving modularity for passes prior to gimple-rtl expansion and to make any notable progress we're going to have to tackle the type system problems. It won't be sexy or fun, but to keep GCC relevant, it's one of the things we need to tackle. Jeff
Re: Long term viability of GCC (was Re: gcc : c++11 : full support : eta?)
On Wed, 2013-01-23 at 19:59 +, Alec Teal wrote: On 23/01/13 19:38, Diego Novillo wrote: [ We have drifted way off the original subject. ] On Wed, Jan 23, 2013 at 2:16 PM, Uday Khedker u...@cse.iitb.ac.in wrote: Yes, absolutely. And GCC community should consider it important to bring in newcomers particularly young students and experimenters from the academia. Why is it that most student projects these days are on LLVM and not on GCC? Had these students been doing projects on GCC, some of them may turn contributors in future. Yes. This is an issue for the long term viability of GCC as a project. In fact, I sometimes think that we may be past the tipping point. Note that the very set of developers that can fix these problems are, traditionally, the least likely to do much about it. These developers are already comfortable with the codebase, they know how to do the things they are hired to do and employers are largely on the same boat. Additionally, established developers will generally resist change, because these changes lead to short-term instability and bugs (the releng/maintainer mindset). Evolving this codebase is largely a thankless and difficult job. It's technically interesting to me, but I know I can only do so much. We have other demands on our time and often this conflicts with the nature of these changes. Some developers have done some work here and there to improve the codebase, but GCC's accumulated technical debt is large. If this trend continues, the pool of experienced GCC developers will eventually start to dwindle. Without developer renewal, GCC will naturally die out. This cycle has happened many times before and it will continue to happen. Yet, it would be interesting to have two or more strong competing open source compilers. The cross-pollination that open source competition encourages is beneficial to all (users and developers). Diego. As I am happy to be finding out though, even from RTL (old pdfs and stuff :)) GCC wasn't what I thought it was, to quote earlier: -- I really have a theory here, I think (like me! I came here in the hope of 'fixing' GCC from what I thought it was to what it is because I, suppose I am loyal, I don't really like BSD, the lack of obligation to keep things free, anyway that'll start a dispute probably so don't worry) it's all the bad press, my impression was GCC is really old and archaic, not very good for developing new optimisations, had a crap IR and there was this newcomer that only made these problems known because it fixes them. I know now that most of them were wrong BTW! Ah, well - the old issue that LLVM has just become a very good marketing machinery (and we've stayed at being a compiler - heh). Richard. You see my point though right? Alec -- Is it not just bad press? The articles perpetuate the Wow look how easy clang is which no one expects of GCC. If you're looking for an easy introduction to GCC (and know Python) you might want to try my Python plugin for GCC: http://gcc-python-plugin.readthedocs.org/en/latest/ It lets you write new GCC passes in Python, exposing GCC's data structures as Python classes and objects, which I hope will make things considerably easier for newcomers. (it covers the tree and gimple parts of the IR; it doesn't really handle RTL yet). It can also generate various nice visualizations of the internals, and being in Python it's relatively easy to hack on. Hope this is helpful Dave [oh, and Uday: am very much enjoying reading your Data Flow Analysis book - thanks for writing it! ]
Re: gcc : c++11 : full support : eta?
On Thu, Jan 24, 2013 at 1:08 PM, Jeff Law l...@redhat.com wrote: On 01/24/2013 10:23 AM, Alexandre Oliva wrote: On Jan 23, 2013, Aldy Hernandez al...@redhat.com wrote: an internal training program Jeff Law devised over a decade ago (*) [Before anybody asks, the training program is probably no longer relevant. So no fair bugging Jeff about it :)]. Yeah. It was focused on the RTL/md part of GCC, with a few simple assignments that amounted to implementing changes in the mn10300-elf port. That was before AM33/2.0 came up; before gimple and SSA, long before tuples and mode iterators. GCC was a very different beast then. The course made me more of an RTL person, which still makes me hope this tree-based stuff a fad and that some day we'll get back to our senses and do SSA in RTL ;-) And the thing to remember about that training program is that it was geared strictly towards backend porting. ie, new version of the frob chip comes out with some new instructions, we need to support them. That was a significant component of Cygnus's business back then. As Alex notes, GCC today is dramatically different and hacking new instructions into existing backends isn't nearly as important as it was 10+ years ago. Training around GCC's implementation of SSA, how GCC's optimization pipeline works, plugins, the propagation engine would be far more interesting and useful. When we made the change from RTL centric to gimple, one of the goals was to make GCC more approachable. I would argue to some degree that was successful, but not nearly as much as I'd hoped. Of course that was over 10 years ago and we're at another point where some significant architectural changes to GCC are needed. Google has kicked some stuff around and Red Hat is kicking stuff around toward that goal. I believe the ultimate focus will be on improving modularity for passes prior to gimple-rtl expansion and to make any notable progress we're going to have to tackle the type system problems. It won't be sexy or fun, but to keep GCC relevant, it's one of the things we need to tackle. Agreed. I do see, however, a few areas where Clang/LLVM have gone that I do not think GCC is currently thinking of entering: toolability (for the lack of a better term). Clang's design follows a different path than g++. It's not just a code generating parser, it is a pure parser that also generates code. The difference makes it suitable for any kind of tool that needs to understand C++: static analyzers, code re-formatters, syntax highlighters, and other similar tools. Additionally, it is designed as a library, so it can be embedded into applications. That is a need that g++ cannot currently satisfy. With plugins, one could do something along those lines, but they are heavier, and are at the mercy of the full compiler. Additionally, g++ has very low fidelity wrt the input program; it breaks down the original C++ input almost immediately. That is not necessarily a bad thing for g++. But, to effectively compete in those areas, it will need to be significantly re-organized. LLVM has similar properties, at least as far as the middle end of the compiler is concerned. GCC still has an edge wrt backend portability. Diego.
Re: gcc : c++11 : full support : eta?
On 01/24/2013 12:55 PM, Diego Novillo wrote: I do see, however, a few areas where Clang/LLVM have gone that I do not think GCC is currently thinking of entering: toolability (for the lack of a better term). Clang's design follows a different path than g++. It's not just a code generating parser, it is a pure parser that also generates code. The difference makes it suitable for any kind of tool that needs to understand C++: static analyzers, code re-formatters, syntax highlighters, and other similar tools. Additionally, it is designed as a library, so it can be embedded into applications. Yup. We kicked stuff in this area around as well as we were discussing the problems early folding presents. In an ideal world, the G++ parser would turn into something that can be used not just for G++, but as a library for other tools that need to parse C++ code (doxygen, gdb and I'm sure there's others). Jeff
Re: gcc : c++11 : full support : eta?
On 24/01/13 19:55, Diego Novillo wrote: ... Agreed. I do see, however, a few areas where Clang/LLVM have gone that I do not think GCC is currently thinking of entering: toolability (for the lack of a better term). Clang's design follows a different path than g++. It's not just a code generating parser, it is a pure parser that also generates code. The difference makes it suitable for any kind of tool that needs to understand C++: static analyzers, code re-formatters, syntax highlighters, and other similar tools. Additionally, it is designed as a library, so it can be embedded into applications. I don't know enough yet but GCC seems to be partitioned, this back and front end, there's some point where there's no GIMPLE and then there is, whenever I've got a big code-blob and need to do something with it where I cannot copy and paste the bits I want to keep, you know, you can't just take the good parts, I've turned to Biology: When DNA replication happens (or protein synthesis - please biologists don't be bionazis) the DNA is not 'unzipped' for very long and doesn't leave the safety of the membrane around the nuclease (this time last year, I would have known the name!) so instead it is transcribed. An enzyme latches onto the 3`UTR end and moves to the 5`UTR end, unzipping the DNA and rezipping it in it's wake, and it transcribes the DNA bases to the complimentary base in RNA, rather than the compliment to DNA's Adenine (thymine) RNA has Uracil. Fun fact. Anyway this fragile DNA structure that can't leave the nuclease or be split up (GCC) can be traversed by this enzyme and spit off useful strands of RNA that expresses the data of the DNA. No fact checking - hope it wasn't to bad, and worthy of writing, with GCC why not add the ability to siphon off useful structures and output a form that can be independent of the DNA that is GCC (serialised form) The thing that'd do this would be inside GCC so would have access to all context and whatever data is available. I think that was a superb metaphor. That is a need that g++ cannot currently satisfy. With plugins, one could do something along those lines, but they are heavier, and are at the mercy of the full compiler. Additionally, g++ has very low fidelity wrt the input program; it breaks down the original C++ input almost immediately. I don't quite follow, as opposed to? (Sorry if dumb question) That is not necessarily a bad thing for g++. But, to effectively compete in those areas, it will need to be significantly re-organized. LLVM has similar properties, at least as far as the middle end of the compiler is concerned. GCC still has an edge wrt backend portability. Diego. Alec
Re: gcc : c++11 : full support : eta?
On Thu, Jan 24, 2013 at 08:11:25PM +, Alec Teal wrote:
On 24/01/13 19:55, Diego Novillo wrote:
...
I don't know enough yet but GCC seems to be partitioned, this back
and front end,
There is also a middle-end in GCC (and IMNSHO the middle-end of GCC is its
biggest part; it is the thing which does not depend much on the source language
and on the target processor system).
FWIW, there is some partial documentation about GCC (notably some slides I have
made) on http://gcc-melt.org/docum.html
(of course the main emphasis is on MELT, but there are some explanations about
GCC internals)
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: gcc : c++11 : full support : eta?
On Thu, Jan 24, 2013 at 3:11 PM, Alec Teal a.t...@warwick.ac.uk wrote: That is a need that g++ cannot currently satisfy. With plugins, one could do something along those lines, but they are heavier, and are at the mercy of the full compiler. Additionally, g++ has very low fidelity wrt the input program; it breaks down the original C++ input almost immediately. I don't quite follow, as opposed to? (Sorry if dumb question) As opposed to an AST that is a very close representation of the original C++ program. Such that if you pretty printed that AST, you'd get something that resembles the original program very closely. Diego.
Re: gcc : c++11 : full support : eta?
On 01/23/2013 08:43 PM, Richard Biener wrote: Ah, well - the old issue that LLVM has just become a very good marketing machinery (and we've stayed at being a compiler - heh). The problem of being on a compiler-only list is that this is becoming a self-evident truth. However, as a meteorologist, I know better (HAH :-)) WRF (http://www.wrf-model.org/index.php) is our eternal Nemesis. It's a free weather forecasting model and data assimilation system developed by the best US academic institutions. WRF has a rapidly growing community of users, and workshops and tutorials are held each year at NCAR. WRF is currently in operational use at NCEP, AFWA and other centers. So it is hopeless to fight it. It is free (our European-community-developed model is not) and it has a *huge* backing from the US academic community. Unfortunately for this virtual reality, it doesn't match the real one. We do still exist, and there is no indication (on the basis of meteorological verification) that we will be dethroned shortly. And yes, we understand why academia is mad with WRF - we *do* understand why they like to have their students play with it (it is much *easier*) - that doesn't mean that a focused course can't make students resident at KNMI (the Dutch Meteorological Institute) familiar enough with *our* weather model to work on it. Don't get your nickers in a twist (as we would say in the seventies). -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: gcc : c++11 : full support : eta?
On 24/01/13 20:18, Diego Novillo wrote: On Thu, Jan 24, 2013 at 3:11 PM, Alec Teal a.t...@warwick.ac.uk wrote: That is a need that g++ cannot currently satisfy. With plugins, one could do something along those lines, but they are heavier, and are at the mercy of the full compiler. Additionally, g++ has very low fidelity wrt the input program; it breaks down the original C++ input almost immediately. I don't quite follow, as opposed to? (Sorry if dumb question) As opposed to an AST that is a very close representation of the original C++ program. Such that if you pretty printed that AST, you'd get something that resembles the original program very closely. I don't really know about GCC and how it parses C++ but could you not just embed more meta-data in GCCs AST? Or even the tokens themselves? or do the two methods mix like oil and water and there really is no compromise that doesn't have two loosers? Alec Diego.
Re: gcc : c++11 : full support : eta?
On 24/01/13 20:16, Basile Starynkevitch wrote: On Thu, Jan 24, 2013 at 08:11:25PM +, Alec Teal wrote: On 24/01/13 19:55, Diego Novillo wrote: ... I don't know enough yet but GCC seems to be partitioned, this back and front end, There is also a middle-end in GCC (and IMNSHO the middle-end of GCC is its biggest part; it is the thing which does not depend much on the source language and on the target processor system). IMNSHO (In My Honest Opinion)? and yes that makes sense, but the same is true of LLVM, that is the middle part, it's far away from the code (but is (rather cooley) able to contain metadata IIRC so you can 'rebuild' parts of where it came from, I've never really looked into it that far) but not near a specific machine. It'd be really cool if GCC could compile to LLVM and also parse it. This has to be worth more than because it is cool and would certainly (read perhaps) link the two communities together. FWIW, there is some partial documentation about GCC (notably some slides I have made) on http://gcc-melt.org/docum.html FWIW? (of course the main emphasis is on MELT, but there are some explanations about GCC internals) I will be reading that soon, I really enjoyed that RTL presentation yesterday, it's nice to have new stuff to read! If you have any other links, I'd love a big pdf or something rather than just... smaller things. Cheers Alec
Re: gcc : c++11 : full support : eta?
On Thu, Jan 24, 2013 at 09:31:50PM +, Alec Teal wrote:
It'd be really cool if GCC could compile to LLVM and also parse it.
There exist a dragonegg plugin to GCC which uses GCC front-end and LLVM
back-end ( middle-end)
http://dragonegg.llvm.org/
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Long term viability of GCC (was Re: gcc : c++11 : full support : eta?)
David Malcolm wrote, On Friday 25 January 2013 12:15 AM: [oh, and Uday: am very much enjoying reading your Data Flow Analysis book - thanks for writing it! ] Thanks David! I am already working on the second version because now I know very many improvements that I would like to make. Should be ready in a couple of years... Uday.
Re: gcc : c++11 : full support : eta?
Toon Moene wrote, On Friday 25 January 2013 02:31 AM: On 01/23/2013 08:43 PM, Richard Biener wrote: Ah, well - the old issue that LLVM has just become a very good marketing machinery (and we've stayed at being a compiler - heh). The problem of being on a compiler-only list is that this is becoming a self-evident truth. However, as a meteorologist, I know better (HAH :-)) WRF (http://www.wrf-model.org/index.php) is our eternal Nemesis. It's a free weather forecasting model and data assimilation system developed by the best US academic institutions. WRF has a rapidly growing community of users, and workshops and tutorials are held each year at NCAR. WRF is currently in operational use at NCEP, AFWA and other centers. So it is hopeless to fight it. It is free (our European-community-developed model is not) and it has a *huge* backing from the US academic community. Unfortunately for this virtual reality, it doesn't match the real one. We do still exist, and there is no indication (on the basis of meteorological verification) that we will be dethroned shortly. And yes, we understand why academia is mad with WRF - we *do* understand why they like to have their students play with it (it is much *easier*) - that doesn't mean that a focused course can't make students resident at KNMI (the Dutch Meteorological Institute) familiar enough with *our* weather model to work on it. Exactly. We have been using our training program since 2007 (and have been incrementally refining it on a continuously). Our experience has been that it has brought down the ramp up period of novices to a couple of week. Personally, when our group started getting into GCC, it took us far longer (also because it could only be driven through students) and hence we decided the change the our focus from putting our research into GCC to doing RD in explaining GCC better. I am convinced that if we agree on ONE courseware and all of us review it and help me improve it, we can make it easy for students and academia --- and perhaps easier than using LLVM. As I said before, all other additional material stays, but we need to have a well identified starting point which continuously evolves as GCC evolves. Uday.
Re: gcc : c++11 : full support : eta?
On 23 January 2013 07:11, Uday Khedker wrote: This is because no matter what one has done, unless one has contributed code, one is not considered a contributor to GCC. There are people credited in http://gcc.gnu.org/onlinedocs/gcc/Contributors.html for documentation or bug triage work.
Re: gcc : c++11 : full support : eta?
I think we need to come out of the documentation mindset. No amount of conventional documentation is going to help. What we need is a training material that included well defined assignments. I agree. At one point, I had a large tutorial presentation. It's dated now, since it's before the tree-ssa era, but we definitely need something like that. High-quality documentation is critical, but isn't where people will be starting.
Re: gcc : c++11 : full support : eta?
On 23/01/13 10:26, Richard Kenner wrote: I think we need to come out of the documentation mindset. No amount of conventional documentation is going to help. What we need is a training material that included well defined assignments. I agree. At one point, I had a large tutorial presentation. It's dated now, since it's before the tree-ssa era, but we definitely need something like that. High-quality documentation is critical, but isn't where people will be starting. Please link it, I enjoy reading it and it couldn't harm!
Re: gcc : c++11 : full support : eta?
Please link it, I enjoy reading it and it couldn't harm! I put it up at http://www.gnat.com/~kenner/gcctut.ppt It's 173 slides, but was last modified in 2000 and wasn't current then. It predates tree-ssa and many of the changes in the way that target macros were handled. But it does talk about: RTL RTL optimizers (though the older versions of some) Tree nodes and fields How to write a front end (though before function-at-a-time) How to port to a new machine
Re: gcc : c++11 : full support : eta?
On Wed, Jan 23, 2013 at 5:26 AM, Richard Kenner ken...@vlsi1.ultra.nyu.edu wrote: I think we need to come out of the documentation mindset. No amount of conventional documentation is going to help. What we need is a training material that included well defined assignments. I agree. At one point, I had a large tutorial presentation. It's dated now, since it's before the tree-ssa era, but we definitely need something like that. High-quality documentation is critical, but isn't where people will be starting. Folks, we have a place for this material and I am constantly badgering people to use it. All the training material, courses, papers, presentations, pictures of design-on-a-napkin, are meant to be linked from http://gcc.gnu.org/wiki/GettingStarted. The wiki has become one of the most dynamic and best sources of such information in GCC. Let's use it! Uday, you have a wealth of experience organizing tutorials and such. Volunteers should not just be limited to code. Tutorials and courses are an excellent way to contribute. The steering committee has nothing to do with this. All they need to be involved in are administrivia matters with the FSF. No need to appoint volunteers, just start doing what you think is right. Organizing the GettingStarted wiki is a fantastic start. Diego.
Re: gcc : c++11 : full support : eta?
Uday Khedker u...@cse.iitb.ac.in writes: I think we need to come out of the documentation mindset. No amount of conventional documentation is going to help. What we need is a training material that included well defined assignments. FWIW, I initially learned GCC by an internal training program Jeff Law devised over a decade ago (*). So perhaps there is some truth to the above statement. Of course, it didn't hurt that I had a cadre of good and patient maintainers willing to answer questions. [Before anybody asks, the training program is probably no longer relevant. So no fair bugging Jeff about it :)]. But anyways, that's just me. Different folk learn differently. Aldy (*) I think Alex Oliva was also a student of the Law training program :).
Re: gcc : c++11 : full support : eta?
Alec Teal a.t...@warwick.ac.uk a écrit: I'd love to help with GCC, without documentation (in fact, without instructions) I have no hope of doing so. Maybe instruct/ask people to do stuff? If I may propose something, I think a reasonable way of starting is to pick an (easy) bug from bugzilla and try to fix it. You can start with an internal compiler error that happens in a front end, for instance. Look at the code in the debugger from the point where it crashes. Step through it while compiling a simple test case to understand what it's doing. Oh, and do all that while having and IRC client not too far; connect to irc.oftc.net#gcc, and do not hesitate to ask people about parts of the code you don't understand. My experience here is that there are *many* people who are *very* friendly and willing to help in the GCC (I'd say GNU Tools in general) community. And hopefully, once you understand that part of the code that is precisely not well documented enough, you'll be able to propose patches to the documentation. You can also subscribe to bugzilla emails and try to reproduce the bugs people file, help reduce their test cases, triage (and comment on) the bugs. This task is utterly appreciated, and with time, that helps you get a better sense of how things are organized, and can provide you with an itch to scratch, so much that you'll start diving into some part of the code sooner than you'd have otherwise expected. Cheers, and please do not be impressed by the size of the code. Like for an elephant, I guess you can eat it one spoon at a time. -- Dodji
Re: gcc : c++11 : full support : eta?
I have been trying to do my stuff for a few years. We conduct a programme called Essential Abstractions in GCC which is aimed at taking a novice to a level from where she can do independent experimentation with GCC internals. I put together a bunch of teaching assistants (about 15 of them) for about 60 participants. Carefully designed programming assignments are an integral part of the training. The program ends with us summarizing the essential abstractions in 17 or 18 pictures with the hope that if one can understand the concepts represented by the pictures, one can walk the maze of the GCC code. You can find the details of the latest offering at http://www.cse.iitb.ac.in/grc/gcc-workshop-12/. I would like to take this training program to the next level but so long it remains my personal baby, my funding agency does not feel that I have accomplished much because they feel that if my program has any merit, the GCC community would adopt it :-( Uday. Aldy Hernandez wrote, On Wednesday 23 January 2013 08:07 PM: Uday Khedkeru...@cse.iitb.ac.in writes: I think we need to come out of the documentation mindset. No amount of conventional documentation is going to help. What we need is a training material that included well defined assignments. FWIW, I initially learned GCC by an internal training program Jeff Law devised over a decade ago (*). So perhaps there is some truth to the above statement. Of course, it didn't hurt that I had a cadre of good and patient maintainers willing to answer questions. [Before anybody asks, the training program is probably no longer relevant. So no fair bugging Jeff about it :)]. But anyways, that's just me. Different folk learn differently. Aldy (*) I think Alex Oliva was also a student of the Law training program :). -- signature.html Dr. Uday Khedker Professor Department of Computer Science Engg. IIT Bombay, Powai, Mumbai 400 076, India. Email : u...@cse.iitb.ac.in Homepage: http://www.cse.iitb.ac.in/~uday Phone : Office -91 (22) 2572 2545 x 7717, 91 (22) 2576 7717 (Direct) Res. -91 (22) 2572 2545 x 8717, 91 (22) 2576 8717 (Direct)
Re: gcc : c++11 : full support : eta?
Uday Khedker u...@cse.iitb.ac.in wrote: I have been trying to do my stuff for a few years. We conduct a programme called Essential Abstractions in GCC which is aimed at taking a novice to a level from where she can do independent experimentation with GCC internals. I put together a bunch of teaching assistants (about 15 of them) for about 60 participants. Carefully designed programming assignments are an integral part of the training. The program ends with us summarizing the essential abstractions in 17 or 18 pictures with the hope that if one can understand the concepts represented by the pictures, one can walk the maze of the GCC code. You can find the details of the latest offering at http://www.cse.iitb.ac.in/grc/gcc-workshop-12/. I would like to take this training program to the next level but so long it remains my personal baby, my funding agency does not feel that I have accomplished much because they feel that if my program has any merit, the GCC community would adopt it :-( Can you hint at what they would consider adopting it? I suppose it is not simply linking to it from the wiki or the website? Richard. Uday. Aldy Hernandez wrote, On Wednesday 23 January 2013 08:07 PM: Uday Khedkeru...@cse.iitb.ac.in writes: I think we need to come out of the documentation mindset. No amount of conventional documentation is going to help. What we need is a training material that included well defined assignments. FWIW, I initially learned GCC by an internal training program Jeff Law devised over a decade ago (*). So perhaps there is some truth to the above statement. Of course, it didn't hurt that I had a cadre of good and patient maintainers willing to answer questions. [Before anybody asks, the training program is probably no longer relevant. So no fair bugging Jeff about it :)]. But anyways, that's just me. Different folk learn differently. Aldy (*) I think Alex Oliva was also a student of the Law training program :).
Re: gcc : c++11 : full support : eta?
On Wed, Jan 23, 2013 at 12:18 PM, Uday Khedker u...@cse.iitb.ac.in wrote: I would like to take this training program to the next level but so long it remains my personal baby, my funding agency does not feel that I have accomplished much because they feel that if my program has any merit, the GCC community would adopt it :-( I would say they have it backwards. The GCC community is the last one who'd adopt such a training program. We already know the content! This kind of training is precisely targeted at newcomers. Diego.
Re: gcc : c++11 : full support : eta?
On 23/01/13 19:05, Richard Biener wrote: Uday Khedker u...@cse.iitb.ac.in wrote: I have been trying to do my stuff for a few years. We conduct a programme called Essential Abstractions in GCC which is aimed at taking a novice to a level from where she can do independent experimentation with GCC internals. I put together a bunch of teaching assistants (about 15 of them) for about 60 participants. Carefully designed programming assignments are an integral part of the training. The program ends with us summarizing the essential abstractions in 17 or 18 pictures with the hope that if one can understand the concepts represented by the pictures, one can walk the maze of the GCC code. You can find the details of the latest offering at http://www.cse.iitb.ac.in/grc/gcc-workshop-12/. I would like to take this training program to the next level but so long it remains my personal baby, my funding agency does not feel that I have accomplished much because they feel that if my program has any merit, the GCC community would adopt it :-( When I rule the world you will not have such problems. Seriously can you not reason with them? Can you hint at what they would consider adopting it? I suppose it is not simply linking to it from the wiki or the website? Richard. Uday. Aldy Hernandez wrote, On Wednesday 23 January 2013 08:07 PM: Uday Khedkeru...@cse.iitb.ac.in writes: I think we need to come out of the documentation mindset. No amount This is being dragged up A LOT actually, and a lot of the clang-vs-gcc myths are just that, ALSO I was lead to believe GCC used some hand-coded stuff for final code output, one of the reasons I liked LLVM is because it seems sensible, I've just read a power-point presentation on RTL, GIMPLE cannot be a step back! Alec. of conventional documentation is going to help. What we need is a training material that included well defined assignments. FWIW, I initially learned GCC by an internal training program Jeff Law devised over a decade ago (*). So perhaps there is some truth to the above statement. Of course, it didn't hurt that I had a cadre of good and patient maintainers willing to answer questions. [Before anybody asks, the training program is probably no longer relevant. So no fair bugging Jeff about it :)]. But anyways, that's just me. Different folk learn differently. Aldy (*) I think Alex Oliva was also a student of the Law training program :). I just want to say you guys have been so nice! Totally not what I expected, so thanks for that!
Re: gcc : c++11 : full support : eta?
On Thursday 24 January 2013 12:39 AM, Diego Novillo wrote: On Wed, Jan 23, 2013 at 12:18 PM, Uday Khedker u...@cse.iitb.ac.in wrote: I would like to take this training program to the next level but so long it remains my personal baby, my funding agency does not feel that I have accomplished much because they feel that if my program has any merit, the GCC community would adopt it :-( I would say they have it backwards. The GCC community is the last one who'd adopt such a training program. We already know the content! This kind of training is precisely targeted at newcomers. Yes, absolutely. And GCC community should consider it important to bring in newcomers particularly young students and experimenters from the academia. Why is it that most student projects these days are on LLVM and not on GCC? Had these students been doing projects on GCC, some of them may turn contributors in future. Uday.
Re: gcc : c++11 : full support : eta?
On 23/01/13 19:16, Uday Khedker wrote: On Thursday 24 January 2013 12:39 AM, Diego Novillo wrote: On Wed, Jan 23, 2013 at 12:18 PM, Uday Khedker u...@cse.iitb.ac.in wrote: I would like to take this training program to the next level but so long it remains my personal baby, my funding agency does not feel that I have accomplished much because they feel that if my program has any merit, the GCC community would adopt it :-( I would say they have it backwards. The GCC community is the last one who'd adopt such a training program. We already know the content! This kind of training is precisely targeted at newcomers. Yes, absolutely. And GCC community should consider it important to bring in newcomers particularly young students and experimenters from the academia. Why is it that most student projects these days are on LLVM and not on GCC? Had these students been doing projects on GCC, some of them may turn contributors in future. Uday. I really have a theory here, I think (like me! I came here in the hope of 'fixing' GCC from what I thought it was to what it is because I, suppose I am loyal, I don't really like BSD, the lack of obligation to keep things free, anyway that'll start a dispute probably so don't worry) it's all the bad press, my impression was GCC is really old and archaic, not very good for developing new optimisations, had a crap IR and there was this newcomer that only made these problems known because it fixes them. I know now that most of them were wrong BTW! Alec
Long term viability of GCC (was Re: gcc : c++11 : full support : eta?)
[ We have drifted way off the original subject. ] On Wed, Jan 23, 2013 at 2:16 PM, Uday Khedker u...@cse.iitb.ac.in wrote: Yes, absolutely. And GCC community should consider it important to bring in newcomers particularly young students and experimenters from the academia. Why is it that most student projects these days are on LLVM and not on GCC? Had these students been doing projects on GCC, some of them may turn contributors in future. Yes. This is an issue for the long term viability of GCC as a project. In fact, I sometimes think that we may be past the tipping point. Note that the very set of developers that can fix these problems are, traditionally, the least likely to do much about it. These developers are already comfortable with the codebase, they know how to do the things they are hired to do and employers are largely on the same boat. Additionally, established developers will generally resist change, because these changes lead to short-term instability and bugs (the releng/maintainer mindset). Evolving this codebase is largely a thankless and difficult job. It's technically interesting to me, but I know I can only do so much. We have other demands on our time and often this conflicts with the nature of these changes. Some developers have done some work here and there to improve the codebase, but GCC's accumulated technical debt is large. If this trend continues, the pool of experienced GCC developers will eventually start to dwindle. Without developer renewal, GCC will naturally die out. This cycle has happened many times before and it will continue to happen. Yet, it would be interesting to have two or more strong competing open source compilers. The cross-pollination that open source competition encourages is beneficial to all (users and developers). Diego.
Re: gcc : c++11 : full support : eta?
On Wed, Jan 23, 2013 at 8:23 PM, Alec Teal a.t...@warwick.ac.uk wrote: On 23/01/13 19:16, Uday Khedker wrote: On Thursday 24 January 2013 12:39 AM, Diego Novillo wrote: On Wed, Jan 23, 2013 at 12:18 PM, Uday Khedker u...@cse.iitb.ac.in wrote: I would like to take this training program to the next level but so long it remains my personal baby, my funding agency does not feel that I have accomplished much because they feel that if my program has any merit, the GCC community would adopt it :-( I would say they have it backwards. The GCC community is the last one who'd adopt such a training program. We already know the content! This kind of training is precisely targeted at newcomers. Yes, absolutely. And GCC community should consider it important to bring in newcomers particularly young students and experimenters from the academia. Why is it that most student projects these days are on LLVM and not on GCC? Had these students been doing projects on GCC, some of them may turn contributors in future. Uday. I really have a theory here, I think (like me! I came here in the hope of 'fixing' GCC from what I thought it was to what it is because I, suppose I am loyal, I don't really like BSD, the lack of obligation to keep things free, anyway that'll start a dispute probably so don't worry) it's all the bad press, my impression was GCC is really old and archaic, not very good for developing new optimisations, had a crap IR and there was this newcomer that only made these problems known because it fixes them. I know now that most of them were wrong BTW! Ah, well - the old issue that LLVM has just become a very good marketing machinery (and we've stayed at being a compiler - heh). Richard. Alec
Re: gcc : c++11 : full support : eta?
On Wed, Jan 23, 2013 at 12:18 PM, Uday Khedker u...@cse.iitb.ac.in wrote: I would like to take this training program to the next level but so long it remains my personal baby, my funding agency does not feel that I have accomplished much because they feel that if my program has any merit, the GCC community would adopt it :-( Uday, As Diego wrote, I am not sure what your funding agency thinks adoption would mean. Experienced GCC developers do not need to adopt your methodology to be productive. However, software developers who attend your workshops and classes should be able to engage the GCC community and contribute patches. Your centre needs to actively engage the GCC community and participate in development. The community does not always reward documentation activity as much as it should, but it also needs people to get involved and participate *in* the community on a regular basis, not work in parallel but distinct from the community. - David
Re: gcc : c++11 : full support : eta?
On 23/01/13 19:43, Richard Biener wrote: On Wed, Jan 23, 2013 at 8:23 PM, Alec Teal a.t...@warwick.ac.uk wrote: On 23/01/13 19:16, Uday Khedker wrote: On Thursday 24 January 2013 12:39 AM, Diego Novillo wrote: On Wed, Jan 23, 2013 at 12:18 PM, Uday Khedker u...@cse.iitb.ac.in wrote: I would like to take this training program to the next level but so long it remains my personal baby, my funding agency does not feel that I have accomplished much because they feel that if my program has any merit, the GCC community would adopt it :-( I would say they have it backwards. The GCC community is the last one who'd adopt such a training program. We already know the content! This kind of training is precisely targeted at newcomers. Yes, absolutely. And GCC community should consider it important to bring in newcomers particularly young students and experimenters from the academia. Why is it that most student projects these days are on LLVM and not on GCC? Had these students been doing projects on GCC, some of them may turn contributors in future. Uday. I really have a theory here, I think (like me! I came here in the hope of 'fixing' GCC from what I thought it was to what it is because I, suppose I am loyal, I don't really like BSD, the lack of obligation to keep things free, anyway that'll start a dispute probably so don't worry) it's all the bad press, my impression was GCC is really old and archaic, not very good for developing new optimisations, had a crap IR and there was this newcomer that only made these problems known because it fixes them. I know now that most of them were wrong BTW! Ah, well - the old issue that LLVM has just become a very good marketing machinery (and we've stayed at being a compiler - heh). Richard. You see my point though right? Alec
Re: Long term viability of GCC (was Re: gcc : c++11 : full support : eta?)
On Wed, Jan 23, 2013 at 8:38 PM, Diego Novillo dnovi...@google.com wrote: [ We have drifted way off the original subject. ] On Wed, Jan 23, 2013 at 2:16 PM, Uday Khedker u...@cse.iitb.ac.in wrote: Yes, absolutely. And GCC community should consider it important to bring in newcomers particularly young students and experimenters from the academia. Why is it that most student projects these days are on LLVM and not on GCC? Had these students been doing projects on GCC, some of them may turn contributors in future. Yes. This is an issue for the long term viability of GCC as a project. In fact, I sometimes think that we may be past the tipping point. Note that the very set of developers that can fix these problems are, traditionally, the least likely to do much about it. These developers are already comfortable with the codebase, they know how to do the things they are hired to do and employers are largely on the same boat. Additionally, established developers will generally resist change, because these changes lead to short-term instability and bugs (the releng/maintainer mindset). Evolving this codebase is largely a thankless and difficult job. It's technically interesting to me, but I know I can only do so much. We have other demands on our time and often this conflicts with the nature of these changes. Some developers have done some work here and there to improve the codebase, but GCC's accumulated technical debt is large. If this trend continues, the pool of experienced GCC developers will eventually start to dwindle. Without developer renewal, GCC will naturally die out. This cycle has happened many times before and it will continue to happen. Yet, it would be interesting to have two or more strong competing open source compilers. The cross-pollination that open source competition encourages is beneficial to all (users and developers). Note that we can't drive GCC into the garage and refactor it for two years. Any refactoring done has to be while being live on the road! Which essentially limits on what kind of refactoring is possible - which also may limit the ultimate outcome of the sum of all refactorings. Always have this in mind before you turn GCC into an even greater mess than it is! The most important refactoring to a newcomer would IMHO be to further disentangle the already present components - both in the source tree structure as well as in separating (and moving together) of interfaces. Next easy part of that job is to create gcc/driver/ (gcc.c, collect2.c, etc.) and gcc/build/ (gen*.c). Then maybe add a getting-started section to the internals manual, eventually just pointing out external resources. Likewise refer to getting started material from contriubte.html which is where contributors will end up I suppose. Richard. Diego.
Re: Long term viability of GCC (was Re: gcc : c++11 : full support : eta?)
On 23/01/13 19:38, Diego Novillo wrote: [ We have drifted way off the original subject. ] On Wed, Jan 23, 2013 at 2:16 PM, Uday Khedker u...@cse.iitb.ac.in wrote: Yes, absolutely. And GCC community should consider it important to bring in newcomers particularly young students and experimenters from the academia. Why is it that most student projects these days are on LLVM and not on GCC? Had these students been doing projects on GCC, some of them may turn contributors in future. Yes. This is an issue for the long term viability of GCC as a project. In fact, I sometimes think that we may be past the tipping point. Note that the very set of developers that can fix these problems are, traditionally, the least likely to do much about it. These developers are already comfortable with the codebase, they know how to do the things they are hired to do and employers are largely on the same boat. Additionally, established developers will generally resist change, because these changes lead to short-term instability and bugs (the releng/maintainer mindset). Evolving this codebase is largely a thankless and difficult job. It's technically interesting to me, but I know I can only do so much. We have other demands on our time and often this conflicts with the nature of these changes. Some developers have done some work here and there to improve the codebase, but GCC's accumulated technical debt is large. If this trend continues, the pool of experienced GCC developers will eventually start to dwindle. Without developer renewal, GCC will naturally die out. This cycle has happened many times before and it will continue to happen. Yet, it would be interesting to have two or more strong competing open source compilers. The cross-pollination that open source competition encourages is beneficial to all (users and developers). Diego. As I am happy to be finding out though, even from RTL (old pdfs and stuff :)) GCC wasn't what I thought it was, to quote earlier: -- I really have a theory here, I think (like me! I came here in the hope of 'fixing' GCC from what I thought it was to what it is because I, suppose I am loyal, I don't really like BSD, the lack of obligation to keep things free, anyway that'll start a dispute probably so don't worry) it's all the bad press, my impression was GCC is really old and archaic, not very good for developing new optimisations, had a crap IR and there was this newcomer that only made these problems known because it fixes them. I know now that most of them were wrong BTW! Ah, well - the old issue that LLVM has just become a very good marketing machinery (and we've stayed at being a compiler - heh). Richard. You see my point though right? Alec -- Is it not just bad press? The articles perpetuate the Wow look how easy clang is which no one expects of GCC. Alec
Re: gcc : c++11 : full support : eta?
On Wed, Jan 23, 2013 at 12:18 PM, Uday Khedker u...@cse.iitb.ac.in wrote: I would like to take this training program to the next level but so long it remains my personal baby, my funding agency does not feel that I have accomplished much because they feel that if my program has any merit, the GCC community would adopt it :-( With Gerald's recent approval, I have added an announcement of the IITB GCC Center to the News items on the GCC website front page. - David
Re: gcc : c++11 : full support : eta?
On Thursday 24 January 2013 12:35 AM, Richard Biener wrote: Uday Khedker u...@cse.iitb.ac.in wrote: I have been trying to do my stuff for a few years. We conduct a programme called Essential Abstractions in GCC which is aimed at taking a novice to a level from where she can do independent experimentation with GCC internals. I put together a bunch of teaching assistants (about 15 of them) for about 60 participants. Carefully designed programming assignments are an integral part of the training. The program ends with us summarizing the essential abstractions in 17 or 18 pictures with the hope that if one can understand the concepts represented by the pictures, one can walk the maze of the GCC code. You can find the details of the latest offering at http://www.cse.iitb.ac.in/grc/gcc-workshop-12/. I would like to take this training program to the next level but so long it remains my personal baby, my funding agency does not feel that I have accomplished much because they feel that if my program has any merit, the GCC community would adopt it :-( Can you hint at what they would consider adopting it? I suppose it is not simply linking to it from the wiki or the website? I know it sounds awkward but a government funding agency has its own notion of what is official and what is not official. In their eyes, the GCC steering committee, the maintainers appointed by the steering committee etc. are official. All others are hobbyists :-) But on a serious note, it would be great to view the course material as more than documentation. The way there are official manuals and official code available on the gcc website (I can't have my own manual and call it GCC manual, or put up my code and call it GCC code), it would be good to have an official courseware. This is very different from putting it as one among so many other things on the wiki. Look at it from the view point of a newcomer. There are so many links and so many documents on the wiki that one does not even know where to begin from. Can we have ONE course for newcomers (of course refined based on the inputs from the developers) which the developers think represent their knowledge well enough for the newcomers? I don't mean to remove other material. We should have as much variety as possible but let there be one agreed upon starting point. After achieving some maturity, a person is not a newcomer and would be able to extract far more out of the other options that exist anyway. I will be very happy to take the responsibility of taking inputs and keep refining my material until we have something that we all feel is better than anything that we have had so far. That is what I mean by adoption of the training program. While I may not like what funding agency says, I do see a valid point in their expectations: They ask me How have you influenced the GCC movement?. They are smart enough to know the difference between what I have done and whether the GCC community cares about it or not :-) Uday.
Re: gcc : c++11 : full support : eta?
On Wed, Jan 23, 2013 at 2:40 PM, Uday Khedker u...@cse.iitb.ac.in wrote: This is very different from putting it as one among so many other things on the wiki. Look at it from the view point of a newcomer. There are so many OK, then. Reorganize GettingStarted to make it prominent and advertise it. Move the other tutorials down below. Make it so a newcomer is not presented with an endless array of links. If something better comes along, then you duke it out with them. Simple as that. Diego.
Re: gcc : c++11 : full support : eta?
On 01/22/2013 06:01 AM, Mayuresh Kathe wrote: Hello, may I know the estimated timeframe by which full support for C++11 would be added in to GCC? Status is here: http://gcc.gnu.org/projects/cxx0x.html As usual, it'll be done when volunteer maintainers do it. Andrew.
Re: gcc : c++11 : full support : eta?
On 22/01/13 09:00, Andrew Haley wrote: On 01/22/2013 06:01 AM, Mayuresh Kathe wrote: Hello, may I know the estimated timeframe by which full support for C++11 would be added in to GCC? Status is here: http://gcc.gnu.org/projects/cxx0x.html As usual, it'll be done when volunteer maintainers do it. Nice, play the volunteer card, while not wrong that was a crap reply. Andrew.
Re: gcc : c++11 : full support : eta?
On 01/22/2013 12:55 PM, Alec Teal wrote: On 22/01/13 09:00, Andrew Haley wrote: On 01/22/2013 06:01 AM, Mayuresh Kathe wrote: Hello, may I know the estimated timeframe by which full support for C++11 would be added in to GCC? Status is here: http://gcc.gnu.org/projects/cxx0x.html As usual, it'll be done when volunteer maintainers do it. Nice, play the volunteer card, while not wrong that was a crap reply. Feel free to produce a better one. Andrew.
Re: gcc : c++11 : full support : eta?
On 22/01/13 14:20, Andrew Haley wrote: On 01/22/2013 12:55 PM, Alec Teal wrote: On 22/01/13 09:00, Andrew Haley wrote: On 01/22/2013 06:01 AM, Mayuresh Kathe wrote: Hello, may I know the estimated timeframe by which full support for C++11 would be added in to GCC? Status is here: http://gcc.gnu.org/projects/cxx0x.html As usual, it'll be done when volunteer maintainers do it. Nice, play the volunteer card, while not wrong that was a crap reply. Feel free to produce a better one. About the time Clang does because GCC now has to compete. How about that? Clang is currently slightly ahead and GCC really needs to change if it is to continue to be the best. Andrew.
Re: gcc : c++11 : full support : eta?
About the time Clang does because GCC now has to compete. How about that? Clang is currently slightly ahead and GCC really needs to change if it is to continue to be the best. Best is measured by many metrics, and it is unrealistic to expect any product to be best in all respects. Anyway, it still comes down to figuring out how to find the resources. Not clear that there is commercial interest in rapid implementation of c++11, we certainly have not heard of any such interest, and in the absence of such commercial interest, we do indeed come down to hoping to find the volunteer help that is needed.
Re: gcc : c++11 : full support : eta?
On 01/22/2013 02:29 PM, Alec Teal wrote: On 22/01/13 14:20, Andrew Haley wrote: On 01/22/2013 12:55 PM, Alec Teal wrote: On 22/01/13 09:00, Andrew Haley wrote: On 01/22/2013 06:01 AM, Mayuresh Kathe wrote: Hello, may I know the estimated timeframe by which full support for C++11 would be added in to GCC? Status is here: http://gcc.gnu.org/projects/cxx0x.html As usual, it'll be done when volunteer maintainers do it. Nice, play the volunteer card, while not wrong that was a crap reply. Feel free to produce a better one. About the time Clang does because GCC now has to compete. How about that? Well, I'm not sure it's actually any more informative. Saying it'll be done when X is done is IMO no better than saying it'll be done when it's done; YMMV. Pointing out that GCC is a co-operative project has to be done from time to time. Some people seem to think that there is a GCC master planner who hands out tasks to the hordes of willing drones. Full support for C++11 is simply an exercise in box ticking; there is still some of C99 missing because no-one cares about it or uses it. Clang is currently slightly ahead and GCC really needs to change if it is to continue to be the best. Andrew.
Re: gcc : c++11 : full support : eta?
On Tue, Jan 22, 2013 at 4:41 AM, Robert Dewar de...@adacore.com wrote: Anyway, it still comes down to figuring out how to find the resources. Not clear that there is commercial interest in rapid implementation of c++11, we certainly have not heard of any such interest, and in the absence of such commercial interest, we do indeed come down to hoping to find the volunteer help that is needed. This is a hard task. A volunteer has to be both willing (easy) and able (very hard). A lot of people that work on GCC have worked on it for a gazillion years. How much code contribution in 2012 came from people who did not work on it prior? Perhaps it'd be worthwhile to consider making the compiler easier to understand, maybe by devoting a lot of effort into the internals documentation. There's a lot of knowledge wrapped up in people that could disappear with one bus factor.
Re: gcc : c++11 : full support : eta?
Perhaps it'd be worthwhile to consider making the compiler easier to understand, maybe by devoting a lot of effort into the internals documentation. There's a lot of knowledge wrapped up in people that could disappear with one bus factor. That is definitely a worthwhile goal, and one that's had mixed success in the past, but: - compilers are extremely complex programs and there's a limit to how much even the best-written internals documentation can explain - even fewer people are interested and competant to write such documentation as there are to do the necessary development work
Re: gcc : c++11 : full support : eta?
On Tue, Jan 22, 2013 at 11:52 AM, NightStrike nightstr...@gmail.com wrote: Perhaps it'd be worthwhile to consider making the compiler easier to understand, maybe by devoting a lot of effort into the internals documentation. There's a lot of knowledge wrapped up in people that could disappear with one bus factor. Agreed. This is one of the motivators for the code evolution projects. New developers need to find a codebase that is easier to hack than the one we found (http://gcc.gnu.org/wiki/ImprovementProjects). Documentation is a big part of that. As it was argued earlier, finding such volunteers is very hard. The job is not easy and it is generally thankless. Diego.
Re: gcc : c++11 : full support : eta?
On 22 January 2013 14:29, Alec Teal a.t...@warwick.ac.uk wrote: On 22/01/13 14:20, Andrew Haley wrote: On 01/22/2013 12:55 PM, Alec Teal wrote: On 22/01/13 09:00, Andrew Haley wrote: On 01/22/2013 06:01 AM, Mayuresh Kathe wrote: Hello, may I know the estimated timeframe by which full support for C++11 would be added in to GCC? Status is here: http://gcc.gnu.org/projects/cxx0x.html As usual, it'll be done when volunteer maintainers do it. Nice, play the volunteer card, while not wrong that was a crap reply. Feel free to produce a better one. About the time Clang does because GCC now has to compete. How about that? Clang is currently slightly ahead and GCC really needs to change if it is to continue to be the best. Crap reply, it's just wishful thinking. Who says GCC has to or will finish when Clang does? Are you going to do the missing work? Or get someone else to? Do you know something those of us actually working on it don't know? If not your answer has no value. Having implemented large chunks of the C++11 standard library unpaid in my spare time, for my own reasons, I'm not competing with anyone and I'm all for Andrew pointing out there's no schedule and progress depends on factors that can't be estimated. A significant proportion of the people using Clang are doing so with libstdc++ not libc++, so they're using our code anyway, how do you say which is best there?
Re: gcc : c++11 : full support : eta?
On 22/01/13 16:57, Diego Novillo wrote: On Tue, Jan 22, 2013 at 11:52 AM, NightStrike nightstr...@gmail.com wrote: Perhaps it'd be worthwhile to consider making the compiler easier to understand, maybe by devoting a lot of effort into the internals documentation. There's a lot of knowledge wrapped up in people that could disappear with one bus factor. Agreed. This is one of the motivators for the code evolution projects. New developers need to find a codebase that is easier to hack than the one we found (http://gcc.gnu.org/wiki/ImprovementProjects). Documentation is a big part of that. I've been disgruntled lately as I was reading GCC is supposed to be a bitch to read! This makes it harder to be used in non-free projects, they want to avoid piping off GCCs forms of data or shimmying it off to another program, I joined this mailing list in fact because I could find no information on the matter and if this is true this is quite depressing. The thought it is that political is the depressing part, but I can see the point. Urgh it's a nasty issue and has been talked to death - I am told - where can I read what's been said already! BTW I am an eager potential contributor but really GCC is BIG! As it was argued earlier, finding such volunteers is very hard. The job is not easy and it is generally thankless. Diego.
Re: gcc : c++11 : full support : eta?
On 22/01/13 17:00, Jonathan Wakely wrote: On 22 January 2013 14:29, Alec Teal a.t...@warwick.ac.uk wrote: On 22/01/13 14:20, Andrew Haley wrote: On 01/22/2013 12:55 PM, Alec Teal wrote: On 22/01/13 09:00, Andrew Haley wrote: On 01/22/2013 06:01 AM, Mayuresh Kathe wrote: Hello, may I know the estimated timeframe by which full support for C++11 would be added in to GCC? Status is here: http://gcc.gnu.org/projects/cxx0x.html As usual, it'll be done when volunteer maintainers do it. Nice, play the volunteer card, while not wrong that was a crap reply. Feel free to produce a better one. About the time Clang does because GCC now has to compete. How about that? Clang is currently slightly ahead and GCC really needs to change if it is to continue to be the best. Crap reply, it's just wishful thinking. Who says GCC has to or will finish when Clang does? Are you going to do the missing work? Or get someone else to? Do you know something those of us actually working on it don't know? If not your answer has no value. I'd like to, that's why I'm here, GCC is a massive amount of code, it's like day 3 of looking at it I realize that right now I have hope of making a worth-while contribution. I do hate the volunteer card though, it's like talking to Vegans anything problem you talk about comes down to Well the orphans I helped in Peru ... . A technical reason of priorities or difficulty, a link to a road map, whatever, it'd be more productive than: Don't winge, it's done by volunteers. OR! A child requesting pudding without finishing their dinner, eat more dinner - I'm full - No room for pudding again, technically true but really unproductive. Having implemented large chunks of the C++11 standard library unpaid in my spare time, for my own reasons, I'm not competing with anyone and I'm all for Andrew pointing out there's no schedule and progress depends on factors that can't be estimated. I'm not saying getting some project managers would be a good thing! A significant proportion of the people using Clang are doing so with libstdc++ not libc++, so they're using our code anyway, how do you say which is best there? Clang has much better error messages, LLVM is a much better IR, Clang uses less memory, it's AST can be serialized, all these things are actually REALLY good, GCC is archaic coming from a time before I was born where computers didn't have the memory to store whole programs in ram (iffy point, yes, but just go with it), hence the source-transaction-compile to object-link all objects and makefiles ALL GOOD THINGS, I am not saying abolish Make or use tinyCC or some extreme form of this, but times have changed, programs are so huge now that a lifetime of devotion by one person wouldn't finish them, using LLVM with some other things for a JIT is a valid use, why write your own JIT compiler when LLVM exists? Anything you write wouldn't be as good. You're one person, so seriously, why all this bitching? Rather than define best! why not talk about the features that are GENERALLY agreed to be good in Clang and non-existent/not as good/bad in GCC and maybe how to add them? Alec
Re: gcc : c++11 : full support : eta?
On 22 January 2013 17:12, Alec Teal wrote: On 22/01/13 17:00, Jonathan Wakely wrote: Crap reply, it's just wishful thinking. Who says GCC has to or will finish when Clang does? Are you going to do the missing work? Or get someone else to? Do you know something those of us actually working on it don't know? If not your answer has no value. I'd like to, that's why I'm here, GCC is a massive amount of code, it's like day 3 of looking at it I realize that right now I have hope of making a worth-while contribution. I do hate the volunteer card though, it's like talking to Vegans anything problem you talk about comes down to Well the orphans I helped in Peru ... . A technical reason of priorities or difficulty, a link to a road map, whatever, it'd be more productive than: Don't winge, it's done by volunteers. There is no road map. The reasons for missing features are recorded in Bugzilla or the mailing list archives, or they're just not done yet because noone's had time. Feel free to propose documentation/website patches, or just update the wiki yourself, to gather that information into once place, *that* would be more productive. A significant proportion of the people using Clang are doing so with libstdc++ not libc++, so they're using our code anyway, how do you say which is best there? Clang has much better error messages, I disagree, I think G++'s template argument deduction failures are far more informative. Please report bugs where you find deficiences, but make sure you've read http://gcc.gnu.org/wiki/ClangDiagnosticsComparison and are using recent versions, not repeating the unhelpful fact that Clang from 2010 has better diagnostics than GCC from 2006. LLVM is a much better IR, Clang uses less memory, it's AST can be serialized, all these things are actually REALLY good, GCC is archaic coming from a time before I was born where computers didn't have the memory to store whole programs in ram (iffy point, yes, but just go with it), hence the source-transaction-compile to object-link all objects and makefiles ALL GOOD THINGS, I am not saying abolish Make or use tinyCC or some extreme form of this, but times have changed, programs are so huge now that a lifetime of devotion by one person wouldn't finish them, using LLVM with some other things for a JIT is a valid use, why write your own JIT compiler when LLVM exists? You seem to have gone off on a tangent. I thought we were talking about C++11 support? Anything you write wouldn't be as good. You're one person, so seriously, why all this bitching? Rather than define best! why not talk about the features that are GENERALLY agreed to be good in Clang and non-existent/not as good/bad in GCC and maybe how to add them? Welcome to the list, please search the archives before assuming you're saying anything new here, we can do without yet another why doesn't GCC be more like Clang? derailment.
Re: gcc : c++11 : full support : eta?
You totally missed the point there. Stop being Mr Defensive btw. Bitching about the year the versions of GCC and Clang were made to try and diffuse just one person's (potentially wrong) perception clang has better error reports than GCC is not what I had in mind. Not sure what I wanted, having said that, but I never thought a mailing list for something like GCC would be this immature. Alec On 22/01/13 17:24, Jonathan Wakely wrote: On 22 January 2013 17:12, Alec Teal wrote: On 22/01/13 17:00, Jonathan Wakely wrote: Crap reply, it's just wishful thinking. Who says GCC has to or will finish when Clang does? Are you going to do the missing work? Or get someone else to? Do you know something those of us actually working on it don't know? If not your answer has no value. I'd like to, that's why I'm here, GCC is a massive amount of code, it's like day 3 of looking at it I realize that right now I have hope of making a worth-while contribution. I do hate the volunteer card though, it's like talking to Vegans anything problem you talk about comes down to Well the orphans I helped in Peru ... . A technical reason of priorities or difficulty, a link to a road map, whatever, it'd be more productive than: Don't winge, it's done by volunteers. There is no road map. The reasons for missing features are recorded in Bugzilla or the mailing list archives, or they're just not done yet because noone's had time. Feel free to propose documentation/website patches, or just update the wiki yourself, to gather that information into once place, *that* would be more productive. A significant proportion of the people using Clang are doing so with libstdc++ not libc++, so they're using our code anyway, how do you say which is best there? Clang has much better error messages, I disagree, I think G++'s template argument deduction failures are far more informative. Please report bugs where you find deficiences, but make sure you've read http://gcc.gnu.org/wiki/ClangDiagnosticsComparison and are using recent versions, not repeating the unhelpful fact that Clang from 2010 has better diagnostics than GCC from 2006. LLVM is a much better IR, Clang uses less memory, it's AST can be serialized, all these things are actually REALLY good, GCC is archaic coming from a time before I was born where computers didn't have the memory to store whole programs in ram (iffy point, yes, but just go with it), hence the source-transaction-compile to object-link all objects and makefiles ALL GOOD THINGS, I am not saying abolish Make or use tinyCC or some extreme form of this, but times have changed, programs are so huge now that a lifetime of devotion by one person wouldn't finish them, using LLVM with some other things for a JIT is a valid use, why write your own JIT compiler when LLVM exists? You seem to have gone off on a tangent. I thought we were talking about C++11 support? Anything you write wouldn't be as good. You're one person, so seriously, why all this bitching? Rather than define best! why not talk about the features that are GENERALLY agreed to be good in Clang and non-existent/not as good/bad in GCC and maybe how to add them? Welcome to the list, please search the archives before assuming you're saying anything new here, we can do without yet another why doesn't GCC be more like Clang? derailment.
Re: gcc : c++11 : full support : eta?
Sorry for totally derailing this Mayuresh Kathe. On 22/01/13 09:00, Andrew Haley wrote: On 01/22/2013 06:01 AM, Mayuresh Kathe wrote: Hello, may I know the estimated timeframe by which full support for C++11 would be added in to GCC? Status is here: http://gcc.gnu.org/projects/cxx0x.html As usual, it'll be done when volunteer maintainers do it. Andrew.
Re: gcc : c++11 : full support : eta?
On 22 January 2013 17:30, Alec Teal wrote: You totally missed the point there. Stop being Mr Defensive btw. Stop swearing and criticising people for responses you don't like. Bitching about the year the versions of GCC and Clang were made to try and diffuse just one person's (potentially wrong) perception clang has better error reports than GCC is not what I had in mind. What makes you think I'm bitching? My point was to draw your attention to an entire wiki page on the subject of diagnostic comparisons, with examples and links to relevant bug repots, to point out we're well aware of the issue and are doing something productive about it. Ranting about Clang's impressive features achieves what exactly?
Re: gcc : c++11 : full support : eta?
On 22 January 2013 16:52, NightStrike wrote: On Tue, Jan 22, 2013 at 4:41 AM, Robert Dewar wrote: Anyway, it still comes down to figuring out how to find the resources. Not clear that there is commercial interest in rapid implementation of c++11, we certainly have not heard of any such interest, and in the absence of such commercial interest, we do indeed come down to hoping to find the volunteer help that is needed. This is a hard task. A volunteer has to be both willing (easy) and able (very hard). A lot of people that work on GCC have worked on it for a gazillion years. How much code contribution in 2012 came from people who did not work on it prior? Volunteers don't necessarily need to be new volunteers. We also rely on existing volunteers continuing to do the work. Perhaps it'd be worthwhile to consider making the compiler easier to understand, maybe by devoting a lot of effort into the internals documentation. There's a lot of knowledge wrapped up in people that could disappear with one bus factor. Of course it's worthwhile, but it's the usual story. Who's going to do it? How do you force volunteers to work on simplifying existing code and documentation? Is that higher priority than finishing something like C++11?
Re: gcc : c++11 : full support : eta?
On 22/01/13 17:40, Jonathan Wakely wrote: On 22 January 2013 17:30, Alec Teal wrote: You totally missed the point there. Stop being Mr Defensive btw. Stop swearing and criticising people for responses you don't like. Bitching about the year the versions of GCC and Clang were made to try and diffuse just one person's (potentially wrong) perception clang has better error reports than GCC is not what I had in mind. What makes you think I'm bitching? My point was to draw your attention to an entire wiki page on the subject of diagnostic comparisons, with examples and links to relevant bug repots, to point out we're well aware of the issue and are doing something productive about it. Ranting about Clang's impressive features achieves what exactly? I really just wanted a serious discussion, it failed. I should clarify: I define bitching to be pointlessly diffusing statements so nothing gets done. Like the error thing well actually that's a myth from some deep dark place where they used a really old GCC and a new Clang, silly, if GCC is better why is it not said Clang has useless error reports! So how could we (you, I know I'm not ready) remedy this? Start telling people GCC doesn't do this legendary folding thing and keeps track of tokens (I read somewhere, I think it was an old paper by Mozilla about Treehydra and Dehydra (now dead) that GCC cannot map things back to lines of source code, then somewhere else that Clang can track stuff though macro-expansions, GCC turns x-x to 0 which causes a problem for static analysis - this is a good optimization but it's being done too early). Have an option where GCC outputs stuff that's verbose and easier for an Ide to parse, I understand a lot of stuff relies on the current way, why not that? Macros are good (if not over-used, there are some VILE ones out there) but debugging macro-ed code is the bane of any programmers' day. If you are going to bitch in reply at least include some links to things worth reading that are ideally quite long and dirty, if you'd respond seriously, it'd be much welcome. I was honestly hoping for a good chat about the pros and cons, what could be done about things, you know interesting stuff, not Stop swearing and criticising people for responses you don't like. Alec.
Re: gcc : c++11 : full support : eta?
On 01/22/2013 01:01 AM, Mayuresh Kathe wrote: Hello, may I know the estimated timeframe by which full support for C++11 would be added in to GCC? GCC 4.8 will be feature-complete except for ref-qualifiers, which should go onto the trunk soon, and perhaps into a later 4.8.x release. Jason
Re: gcc : c++11 : full support : eta?
On 22/01/13 17:47, Jonathan Wakely wrote: On 22 January 2013 16:52, NightStrike wrote: On Tue, Jan 22, 2013 at 4:41 AM, Robert Dewar wrote: Anyway, it still comes down to figuring out how to find the resources. Not clear that there is commercial interest in rapid implementation of c++11, we certainly have not heard of any such interest, and in the absence of such commercial interest, we do indeed come down to hoping to find the volunteer help that is needed. This is a hard task. A volunteer has to be both willing (easy) and able (very hard). A lot of people that work on GCC have worked on it for a gazillion years. How much code contribution in 2012 came from people who did not work on it prior? Volunteers don't necessarily need to be new volunteers. We also rely on existing volunteers continuing to do the work. Perhaps it'd be worthwhile to consider making the compiler easier to understand, maybe by devoting a lot of effort into the internals documentation. There's a lot of knowledge wrapped up in people that could disappear with one bus factor. Of course it's worthwhile, but it's the usual story. Who's going to do it? How do you force volunteers to work on simplifying existing code and documentation? Is that higher priority than finishing something like C++11? Perhaps, if simplifying + documenting the existing allows a higher power (work time / unit time, not work as in lines of code or something) to be applied to GCC then yes it could be, perhaps this should be discussed? I am eager (I doubt I am alone!) to help with GCC, I've read countless books on compiling, created a language (work stuff, not like c++, a scripting language, wont bore you with it), looked at how other languages are created (to anyone searching [like I was once] look up a no frills introduction to the 5.1 Lua VM and looking up Lua's compliler, it's implemented in Lua, C, Java... probably some others), loved it. I'd love to help with GCC, without documentation (in fact, without instructions) I have no hope of doing so. Maybe instruct/ask people to do stuff? I digress, but this certainly should be considered in more detail.
Re: gcc : c++11 : full support : eta?
On 22 January 2013 18:02, Alec Teal wrote: On 22/01/13 17:47, Jonathan Wakely wrote: On 22 January 2013 16:52, NightStrike wrote: On Tue, Jan 22, 2013 at 4:41 AM, Robert Dewar wrote: Anyway, it still comes down to figuring out how to find the resources. Not clear that there is commercial interest in rapid implementation of c++11, we certainly have not heard of any such interest, and in the absence of such commercial interest, we do indeed come down to hoping to find the volunteer help that is needed. This is a hard task. A volunteer has to be both willing (easy) and able (very hard). A lot of people that work on GCC have worked on it for a gazillion years. How much code contribution in 2012 came from people who did not work on it prior? Volunteers don't necessarily need to be new volunteers. We also rely on existing volunteers continuing to do the work. Perhaps it'd be worthwhile to consider making the compiler easier to understand, maybe by devoting a lot of effort into the internals documentation. There's a lot of knowledge wrapped up in people that could disappear with one bus factor. Of course it's worthwhile, but it's the usual story. Who's going to do it? How do you force volunteers to work on simplifying existing code and documentation? Is that higher priority than finishing something like C++11? Perhaps, if simplifying + documenting the existing allows a higher power (work time / unit time, not work as in lines of code or something) to be applied to GCC then yes it could be, perhaps this should be discussed? I am eager (I doubt I am alone!) to help with GCC, I've read countless books on compiling, created a language (work stuff, not like c++, a scripting language, wont bore you with it), looked at how other languages are created (to anyone searching [like I was once] look up a no frills introduction to the 5.1 Lua VM and looking up Lua's compliler, it's implemented in Lua, C, Java... probably some others), loved it. I'd love to help with GCC, without documentation (in fact, without instructions) I have no hope of doing so. Maybe instruct/ask people to do stuff? Please suggest documentation improvements as you learn about GCC's internals. You're in the best position to do so, because you're the target audience of that documentation and the people who already know the details don't need the docs and are busy working on the gory details. I digress, but this certainly should be considered in more detail. It has been. Many, many times. No matter how often you consider it you cannot instruct volunteers to work on something they don't want to work on. I started contributing to GCC by helping with documentation, and I still fix docs and write wiki pages to improve things, but obviously I can't do it all. It would be nice if for once the people saying we should improve the docs actually helped out.
Re: gcc : c++11 : full support : eta?
On 22 January 2013 17:51, Alec Teal wrote: On 22/01/13 17:40, Jonathan Wakely wrote: On 22 January 2013 17:30, Alec Teal wrote: You totally missed the point there. Stop being Mr Defensive btw. Stop swearing and criticising people for responses you don't like. Bitching about the year the versions of GCC and Clang were made to try and diffuse just one person's (potentially wrong) perception clang has better error reports than GCC is not what I had in mind. What makes you think I'm bitching? My point was to draw your attention to an entire wiki page on the subject of diagnostic comparisons, with examples and links to relevant bug repots, to point out we're well aware of the issue and are doing something productive about it. Ranting about Clang's impressive features achieves what exactly? I really just wanted a serious discussion, it failed. I should clarify: I define bitching to be pointlessly diffusing statements so nothing gets done. Please check GCC's changelogs before you tell me I'm acting so nothing gets done. Like the error thing well actually that's a myth from some deep dark place where they used a really old GCC and a new Clang, silly, if GCC is better why is it not said Clang has useless error reports! Because it doesn't. But the frequently repeated GCC has terrible error reports is not as true as it used to be. So how could we (you, I know I'm not ready) remedy this? Start telling people GCC doesn't do this legendary folding thing and keeps track of tokens (I read somewhere, I think it was an old paper by Mozilla about Treehydra and Dehydra (now dead) that GCC cannot map things back to lines of source code, then somewhere else that Clang can track stuff though macro-expansions, GCC turns x-x to 0 which causes a problem for static analysis - this is a good optimization but it's being done too early). Have an option where GCC outputs stuff that's verbose and easier for an Ide to parse, I understand a lot of stuff relies on the current way, why not that? Macros are good (if not over-used, there are some VILE ones out there) but debugging macro-ed code is the bane of any programmers' day. Do you mean like the Automatic Macro Expansion section of http://gcc.gnu.org/wiki/ClangDiagnosticsComparison ? If you are going to bitch in reply at least include some links to things worth reading that are ideally quite long and dirty, if you'd respond seriously, it'd be much welcome. I'm not bitching, I'm giving you pointers to where this has already been discussed, but you don't seem interested in reading it. I'm sorry if that page isn't long or dirty enough, maybe you'd like to help contribute to it? Or suggest improvments? But you do need to read it first, because you're raising points that are already documented. I was honestly hoping for a good chat about the pros and cons, what could be done about things, you know interesting stuff, not Stop swearing and criticising people for responses you don't like. Please get up to speed on the current status of GCC or a chat is wasting people's time. This list is not a chat room. File bugs, read about existing bugs, point out *concrete* deficiencies in the compiler or libraries, and people will be happy to discuss it.
Re: gcc : c++11 : full support : eta?
On 01/22/2013 05:47 PM, Jonathan Wakely wrote: On 22 January 2013 16:52, NightStrike wrote: Perhaps it'd be worthwhile to consider making the compiler easier to understand, maybe by devoting a lot of effort into the internals documentation. There's a lot of knowledge wrapped up in people that could disappear with one bus factor. Of course it's worthwhile, but it's the usual story. Who's going to do it? How do you force volunteers to work on simplifying existing code and documentation? Is that higher priority than finishing something like C++11? I've come to the conclusion that a real industrial-strength compiler like GCC with as many targets as it has is just going to be hard to understand, no matter what you do. There is a lot of code, and there is no quick way to be an effective GCC maintainer. I'm now working on the HotSpot VM, and it's much the same experience. Internals change, and there is a very great risk that detailed internals documentation will become obsolete by the time it's completed. For example, I used to think that it would be a good idea to document the tree form(s), but I now realize that the file tree.h is exactly what is required. Andrew.
Re: gcc : c++11 : full support : eta?
For example, I used to think that it would be a good idea to document the tree form(s), but I now realize that the file tree.h is exactly what is required. Indeed. And we do try hard to make sure that the comments are updated when the contents are. That's why I'm not sure a big fan of these automated documentation generators. What's important is the *content*. And if the content is in the .h file, it can be read from there. If it isn't, or isn't up to date, then all these programs do is illustrate GIGO.
Re: gcc : c++11 : full support : eta?
On 01/22/2013 05:51 PM, Alec Teal wrote: I really just wanted a serious discussion, it failed. I should clarify: I define bitching to be pointlessly diffusing statements so nothing gets done. Like the error thing well actually that's a myth from some deep dark place where they used a really old GCC and a new Clang, silly, if GCC is better why is it not said Clang has useless error reports! OK, OK, let's all take a deep breath and make this a serious discussion, then. It's not too late. So how could we (you, I know I'm not ready) remedy this? Start telling people GCC doesn't do this legendary folding thing and keeps track of tokens (I read somewhere, I think it was an old paper by Mozilla about Treehydra and Dehydra (now dead) that GCC cannot map things back to lines of source code, then somewhere else that Clang can track stuff though macro-expansions, GCC turns x-x to 0 which causes a problem for static analysis - this is a good optimization but it's being done too early). Folding is done very early in GCC, in the front ends. It would be possible to nullify fold() so that it didn't do anything, but a few places in the compiler require it. Have an option where GCC outputs stuff that's verbose and easier for an Ide to parse, I understand a lot of stuff relies on the current way, why not that? Macros are good (if not over-used, there are some VILE ones out there) but debugging macro-ed code is the bane of any programmers' day. We know. The move to C++ will help that. If you are going to bitch in reply at least include some links to things worth reading that are ideally quite long and dirty, if you'd respond seriously, it'd be much welcome. I was honestly hoping for a good chat about the pros and cons, what could be done about things, you know interesting stuff, not Stop swearing and criticising people for responses you don't like. Let he who is without sin cast the first stone. Andrew.
Re: gcc : c++11 : full support : eta?
On 22/01/13 18:00, Andrew Haley wrote: On 01/22/2013 05:51 PM, Alec Teal wrote: I really just wanted a serious discussion, it failed. I should clarify: I define bitching to be pointlessly diffusing statements so nothing gets done. Like the error thing well actually that's a myth from some deep dark place where they used a really old GCC and a new Clang, silly, if GCC is better why is it not said Clang has useless error reports! OK, OK, let's all take a deep breath and make this a serious discussion, then. It's not too late. So how could we (you, I know I'm not ready) remedy this? Start telling people GCC doesn't do this legendary folding thing and keeps track of tokens (I read somewhere, I think it was an old paper by Mozilla about Treehydra and Dehydra (now dead) that GCC cannot map things back to lines of source code, then somewhere else that Clang can track stuff though macro-expansions, GCC turns x-x to 0 which causes a problem for static analysis - this is a good optimization but it's being done too early). Folding is done very early in GCC, in the front ends. It would be possible to nullify fold() so that it didn't do anything, but a few places in the compiler require it. Have an option where GCC outputs stuff that's verbose and easier for an Ide to parse, I understand a lot of stuff relies on the current way, why not that? Macros are good (if not over-used, there are some VILE ones out there) but debugging macro-ed code is the bane of any programmers' day. We know. The move to C++ will help that. I meant out there not with GCC, I do think macros have a use, a report of the form expanded from: would be helpful, and some sort of callstack-like output? If you are going to bitch in reply at least include some links to things worth reading that are ideally quite long and dirty, if you'd respond seriously, it'd be much welcome. I was honestly hoping for a good chat about the pros and cons, what could be done about things, you know interesting stuff, not Stop swearing and criticising people for responses you don't like. Let he who is without sin cast the first stone. Andrew.
Re: gcc : c++11 : full support : eta?
On 22 January 2013 19:13, Alec Teal wrote: I meant out there not with GCC, I do think macros have a use, a report of the form expanded from: would be helpful, and some sort of callstack-like output? GCC 4.8 does something like that. It isn't perfect yet, but it's pretty good.
Re: gcc : c++11 : full support : eta?
Robert Dewar wrote: About the time Clang does because GCC now has to compete. How about that? Clang is currently slightly ahead and GCC really needs to change if it is to continue to be the best. Best is measured by many metrics, and it is unrealistic to expect any product to be best in all respects. Anyway, it still comes down to figuring out how to find the resources. Not clear that there is commercial interest in rapid implementation of c++11, we certainly have not heard of any such interest, and in the absence of such commercial interest, we do indeed come down to hoping to find the volunteer help that is needed. Some months ago, I had a small talk with a professor from a local university, department for computer science. Some of the research is about (auto) vectorization and I was curious what he says about compilers. He said that most students are interested in cool topics like networking, artificial intelligence, robotics, image recognition, etc. and that compiler technology is regarded as uncool, boring. He also said that the few students that start on compilers, typically give up with GCC after several weeks or even months with frustration because they don't manage to find a start or understand the general structure or are blocked by nasty details from a completely other part of the compiler that they are not aware of or don't understand and nobody would explain to them. He said that the students decide to work on LLVM because it would take about 1 week or so until they can add their own small extension, find many examples, good and friendly responsiveness in the mailing lists, find comprehensible source documentation, appreciate the better modularity and structure, things of that kind. When I started with GCC, something was unclear to me and I asked a question in the gcc lists. The answer was basically: From your question it is obvious that you don't understand anything. Hire a contract GCC developer to implement what you want. You will never contribute anything useful to GCC. My volunteering for GCC is of private nature. Being familiar with gcc as a user, and the compiler producing reasonable code for the ternary what the fuck is -- what? target supported by GCC, I wanted to have a look under the surface, fix bugs, add mini-optimizations for which I am reasonably sure that they don't break too much, etc. About 1 1/2 years elapsed from my first request for a copyright assignment form (for private!) until this document was sent to me by the FSF... It is true that features of a software are important, same for stability and usability. But what's also inevitable for a project like GCC is that it's internals are comprehensible and the software is well designed and potential contributors are welcome and don't stumble around alone in the fog. Otherwise, the software will die sooner or later because it will run out of developers and / or it turns unmaintainable. The success of LLVM shows that there is market or need or whatever you call it for a compiler, and if GCC does not improve his shortcomings, it will lose, IMO. GCC has historical ballast from around 25 years now. The situation of internals documentation and internal structure (SSA, reasonable(!) subset of C++, pass manager, RTL iterators, ...) improved a lot over the last years and I completely agree with: Richard Kenner wrote: compilers are extremely complex programs and there's a limit to how much even the best-written internals documentation can explain Learning is effort -- both for the learner /and/ the teacher or the one that (tries to) share his knowledge. The more complex a matter is, and the more pitfalls and misleads-of-intuition there are, the more important is this transfer of knowledge by the spoken word. And GCC could get easier to read. One example: The implementation language of GCC is not well suited to express code transformations. (C vs. C++ makes not a big difference with code like XEXP (XEXP (XEXP (a, 0), 0), 1) vs. a-xexp(1)-xexp(0)-xexp(0) What's needed is a language that can neatly represent this, and that's the reason why RTL is there: Nobody would even think about writing insn-recog, insn-emit, insn-attrtab etc. by hand. It's all written in RTL and transformed to the implementation language. The C / C++ sources that transform / match / analyze trees and rtxes are plain C. Reading these sources, nothing reminds you of the structure of the code that is to be transformed / matched / analyzed. It's all hand-coded in C and looks considerably different to a tree or RTL dump. Describing transformations like specific if-else to min in a more appropriate representation than big clauses, would greatly increase legibility and maybe also stability and robustness, could add checking, and most of these transformations would be self-explanatory to the reader. Johann -- We could, of course, use any notation we want; do
Re: gcc : c++11 : full support : eta?
The C / C++ sources that transform / match / analyze trees and rtxes are plain C. Reading these sources, nothing reminds you of the structure of the code that is to be transformed / matched / analyzed. It's all hand-coded in C and looks considerably different to a tree or RTL dump. While true, I think that, overall, is not one of the harder concepts and parts of the compiler to understand.
Re: gcc : c++11 : full support : eta?
What does this mean for the Concurrency section, it has 8xNo at the moment? Franz Am 22.01.2013 19:01, schrieb Jason Merrill: On 01/22/2013 01:01 AM, Mayuresh Kathe wrote: Hello, may I know the estimated timeframe by which full support for C++11 would be added in to GCC? GCC 4.8 will be feature-complete except for ref-qualifiers, which should go onto the trunk soon, and perhaps into a later 4.8.x release. Jason
Re: gcc : c++11 : full support : eta?
On Tuesday 22 January 2013 10:27 PM, Richard Kenner wrote: Perhaps it'd be worthwhile to consider making the compiler easier to understand, maybe by devoting a lot of effort into the internals documentation. There's a lot of knowledge wrapped up in people that could disappear with one bus factor. That is definitely a worthwhile goal, and one that's had mixed success in the past, but: - compilers are extremely complex programs and there's a limit to how much even the best-written internals documentation can explain - even fewer people are interested and competant to write such documentation as there are to do the necessary development work This is because no matter what one has done, unless one has contributed code, one is not considered a contributor to GCC. I had said in http://gcc.gnu.org/ml/gcc/2012-11/msg00270.html So while we continue to improve the technology, we have to also give due importance to making it easier for newer people to become contributors to the technology. GCC is not just about a code that works. It is also about building succinct explanations of what that code is and why it has been designed the way it is. The way code maintainers are appointed, I think we need to identify and appoint people who would be willing to take the responsibility so that the developers could rally around such activities to make them more meaningful. We need to build a group whose primary responsibility is not development but who understand the nuances of the development and can engage with academia and attract people who can contribute to GCC. And such a group cannot be identified using the criteria of code submitted. For every piece of code, there are dozens of people who take keen interest in it, express opinion on it, review it critically and contribute to improving it because eventually it could go in the compiler. Unless there is an express statement from the steering committee that tutorials and training material should be accorded a similar status, they would remain neglected and personal projects with limited reach. Of course even in the presence of an official mandate, there is no guarantee that things will change but we would not know until we have tried :-) Uday. Dr. Uday Khedker Professor Department of Computer Science Engg. IIT Bombay, Powai, Mumbai 400 076, India. Email : u...@cse.iitb.ac.in Homepage: http://www.cse.iitb.ac.in/~uday Phone : Office -91 (22) 2572 2545 x 7717, 91 (22) 2576 7717 (Direct) Res. -91 (22) 2572 2545 x 8717, 91 (22) 2576 8717 (Direct)
Re: gcc : c++11 : full support : eta?
On 23/01/13 07:11, Uday Khedker wrote: On Tuesday 22 January 2013 10:27 PM, Richard Kenner wrote: Perhaps it'd be worthwhile to consider making the compiler easier to understand, maybe by devoting a lot of effort into the internals documentation. There's a lot of knowledge wrapped up in people that could disappear with one bus factor. That is definitely a worthwhile goal, and one that's had mixed success in the past, but: - compilers are extremely complex programs and there's a limit to how much even the best-written internals documentation can explain - even fewer people are interested and competant to write such documentation as there are to do the necessary development work This is because no matter what one has done, unless one has contributed code, one is not considered a contributor to GCC. I had said in http://gcc.gnu.org/ml/gcc/2012-11/msg00270.html So while we continue to improve the technology, we have to also give due importance to making it easier for newer people to become contributors to the technology. GCC is not just about a code that works. It is also about building succinct explanations of what that code is and why it has been designed the way it is. The way code maintainers are appointed, I think we need to identify and appoint people who would be willing to take the responsibility so that the developers could rally around such activities to make them more meaningful. We need to build a group whose primary responsibility is not development but who understand the nuances of the development and can engage with academia and attract people who can contribute to GCC. And such a group cannot be identified using the criteria of code submitted. For every piece of code, there are dozens of people who take keen interest in it, express opinion on it, review it critically and contribute to improving it because eventually it could go in the compiler. Unless there is an express statement from the steering committee that tutorials and training material should be accorded a similar status, they would remain neglected and personal projects with limited reach. Of course even in the presence of an official mandate, there is no guarantee that things will change but we would not know until we have tried :-) Uday. Dr. Uday Khedker Professor Department of Computer Science Engg. IIT Bombay, Powai, Mumbai 400 076, India. Email : u...@cse.iitb.ac.in Homepage: http://www.cse.iitb.ac.in/~uday Phone : Office - 91 (22) 2572 2545 x 7717, 91 (22) 2576 7717 (Direct) Res. - 91 (22) 2572 2545 x 8717, 91 (22) 2576 8717 (Direct) So in all seriousness, why GCC? I suppose the volume of LLVM/Clang stuff saying how great it is is misleading? Please link GCCs half or write a good few pages on it please. This is serious I'd love to read it and know more of how the two differ. I fear this coming across as sarcastic but really no, I'd love to read such a thing. BTW I plan to get involved, I'm new, GCC is massive Alec
Re: gcc : c++11 : full support : eta?
On Wednesday 23 January 2013 01:12 PM, Alec Teal wrote: So in all seriousness, why GCC? I suppose the volume of LLVM/Clang stuff saying how great it is is misleading? Please link GCCs half or write a good few pages on it please. This is serious I'd love to read it and know more of how the two differ. I fear this coming across as sarcastic but really no, I'd love to read such a thing. LLVM is far easier to understand and use but perhaps not as extensive and comprehensive. BTW I plan to get involved, I'm new, GCC is massive Please visit http://www.cse.iitb.ac.in/grc/ and look at the training material (eg. http://www.cse.iitb.ac.in/grc/gcc-workshop-12/index.php?page=slides). I think we need to come out of the documentation mindset. No amount of conventional documentation is going to help. What we need is a training material that included well defined assignments. Uday.
Re: gcc : c++11 : full support : eta?
On 23/01/13 07:48, Uday Khedker wrote: On Wednesday 23 January 2013 01:12 PM, Alec Teal wrote: So in all seriousness, why GCC? I suppose the volume of LLVM/Clang stuff saying how great it is is misleading? Please link GCCs half or write a good few pages on it please. This is serious I'd love to read it and know more of how the two differ. I fear this coming across as sarcastic but really no, I'd love to read such a thing. LLVM is far easier to understand and use but perhaps not as extensive and comprehensive. BTW I plan to get involved, I'm new, GCC is massive Please visit http://www.cse.iitb.ac.in/grc/ and look at the training material (eg. http://www.cse.iitb.ac.in/grc/gcc-workshop-12/index.php?page=slides). I think we need to come out of the documentation mindset. No amount of conventional documentation is going to help. What we need is a training material that included well defined assignments. Uday. Thank you! Alec
Re: gcc : c++11 : full support : eta?
Uday Khedker u...@cse.iitb.ac.in wrote: On Tuesday 22 January 2013 10:27 PM, Richard Kenner wrote: Perhaps it'd be worthwhile to consider making the compiler easier to understand, maybe by devoting a lot of effort into the internals documentation. There's a lot of knowledge wrapped up in people that could disappear with one bus factor. That is definitely a worthwhile goal, and one that's had mixed success in the past, but: - compilers are extremely complex programs and there's a limit to how much even the best-written internals documentation can explain - even fewer people are interested and competant to write such documentation as there are to do the necessary development work This is because no matter what one has done, unless one has contributed code, one is not considered a contributor to GCC. I had said in http://gcc.gnu.org/ml/gcc/2012-11/msg00270.html So while we continue to improve the technology, we have to also give due importance to making it easier for newer people to become contributors to the technology. GCC is not just about a code that works. It is also about building succinct explanations of what that code is and why it has been designed the way it is. The way code maintainers are appointed, I think we need to identify and appoint people who would be willing to take the responsibility so that the developers could rally around such activities to make them more meaningful. We need to build a group whose primary responsibility is not development but who understand the nuances of the development and can engage with academia and attract people who can contribute to GCC. And such a group cannot be identified using the criteria of code submitted. For every piece of code, there are dozens of people who take keen interest in it, express opinion on it, review it critically and contribute to improving it because eventually it could go in the compiler. Unless there is an express statement from the steering committee that tutorials and training material should be accorded a similar status, they would remain neglected and personal projects with limited reach. Of course even in the presence of an official mandate, there is no guarantee that things will change but we would not know until we have tried :-) There is no need to involve the steering committee in anything. If you believe that building such a group (of volunteers) is good for gcc consider yourself the volunteer to build it! Richard. Uday. Dr. Uday Khedker Professor Department of Computer Science Engg. IIT Bombay, Powai, Mumbai 400 076, India. Email : u...@cse.iitb.ac.in Homepage: http://www.cse.iitb.ac.in/~uday Phone : Office - 91 (22) 2572 2545 x 7717, 91 (22) 2576 7717 (Direct) Res. - 91 (22) 2572 2545 x 8717, 91 (22) 2576 8717 (Direct)
