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 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 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 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 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 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 Cauldron: Notes from the C++ ABI BOF
On 01/10/2013 08:58 PM, Cary Coutant wrote: Normally, the version identifier is applied to a type. It then propagates to any declaration using that type, whether it's another type or function or variable. For struct/union/class types, if any member or base class has an attached version identifier (excluding static data members, static member functions, and non-virtual member functions), we attach the version identifier to the enclosing type. How does this handle incomplete types? When we see a forward declaration of a class, we don't know its member/base types, so we can't propagate. Jason
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 n
libatomic multilib testing
I was wondering if anyone else is seeing problems running the libatomic testsuite with a multilib target? It seems to have started failing for me over the weekend but I can't seem to find any changes that would have caused this. I am running using the qemu simulator, and it works fine for the GCC and libstdc++ testing but with libatomic I see: spawn /mips/arch/overflow/codesourcery/mips-linux-gnu/pro/release/2012.03-67/Linux/bin/mips-linux-gnu-qemu -r 2.6.38 ./atomic-compare-exchange-1.exe ./atomic-compare-exchange-1.exe: error while loading shared libraries: libpthread.so.0: cannot open shared object file: No such file or directory FAIL: libatomic.c/atomic-compare-exchange-1.c execution test Additionally, when the testing is finished I exit with a 'Error 2', but I think most testing, even when there are problems, should exit with '0'. make[2]: Leaving directory `/local/home/sellcey/gcc/libatomic/obj-mips-mti-linux-gnu/gcc/final/mips-mti-linux-gnu/libatomic' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/local/home/sellcey/gcc/libatomic/obj-mips-mti-linux-gnu/gcc/final/mips-mti-linux-gnu/libatomic' make: *** [check-target-libatomic] Error 2 Steve Ellcey sell...@mips.com
Re: GCC Cauldron: Notes from the C++ ABI BOF
>> Normally, the version identifier is applied to a type. It then >> propagates to any declaration using that type, whether it's another >> type or function or variable. For struct/union/class types, if any >> member or base class has an attached version identifier (excluding >> static data members, static member functions, and non-virtual member >> functions), we attach the version identifier to the enclosing type. > > How does this handle incomplete types? When we see a forward declaration of > a class, we don't know its member/base types, so we can't propagate. I believe we required an explicit attribute on the forward declaration in such a case. The compiler would complain if the version_id on the forward declaration didn't match that of the definition, allowing us to catch these cases at compile time (at least if the forward declaration and the definition are ever visible in the same translation unit). In practice, this was a mechanism of last resort, and it was used infrequently enough (I think struct utsname may have been the only type we were using it for when I left) that the known loopholes were not a real concern. (Other known loopholes included assembly code, Fortran, and typecasting.) -cary
RE: Caller save mode on MIPS
Richard Sandiford [mailto:rdsandif...@googlemail.com] wrote: > > > From http://gcc.gnu.org/ml/gcc-patches/2001-02/msg01480.html, > > the patch defines HARD_REGNO_CALLER_SAVE_MODE to return > proper mode for i386. > > For MIPS, we may have: > > Ex: > > #define HARD_REGNO_CALLER_SAVE_MODE(REGNO, NREGS, MODE) > \ > >((MODE) == VOIDmode ? choose_hard_reg_mode ((REGNO), > (NREGS), false) \ > >: (MODE)) > > > > Any feedback about adding HARD_REGNO_CALLER_SAVE_MODE to > MIPS? Thanks! > > Sounds like a good idea. > > Richard > I will run regression tests and post a patch later. Thanks a lot! Regards, Chao-ying
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 > >
hard typdef - proposal - I know it's not in the standard
Hello,
This suggestion is obviously about typdefs and discusses a *theoretical*
implementation, well a few of them. Anyway please do read this though.
I'm really sorry for the poor structure, my hands are really cold and
I'm quite tired.
I understand that this issue has been discussed A LOT and there are ways
around the limitation, I suspect what I write is nothing new, I don't
claim to be the first ever.
Why not:
make an "optional keyword", "hard", have a meaning if before "typedef",
I suggest tokenising "hard" as a normal token (however it is processed
now why change it? I am not sure on GCCs exact grammar for c languages)
but if AND ONLY if it is before a "typdef" treat it differently, as far
as I know a typedef can only occur at the beginning of a statement so
this should mean it doesn't break anything.
It'd break something if put before "struct" obviously, because struct
need not occur at the beginning of a statement, I can't see the typdef
thing being a problem, it never occurs anywhere else, and this construct
need not be valid anywhere else.
Problems:
1)Not all compilers would be happy with this.
Fix:
I'm sure gcc must define something for the preprocessor that'll exist if
and only if GCC is the compiler? Use this to create a definition for
hard (as "hard") if and only if GCC is the compiler, else define "hard"
as an empty definition (nothing), this way any other compilers wont even
see the "hard" before a typedef. If GCC recognises half without a macro
this means those using just GCC would be fine but they need only put a
constant in a header file.
I am not sure how the preprocessor would handle a keyword named constant
("#define hard hard" is what I'm thinking? Wish I could try it now) but
I am certain "#define HARD hard" would work, while ugly this does make
compatibility easy.
Pros:
The joy of many.
Alec
Sorry again for the awful new-line structure, I'm tired and my fingers
are numb.
Re: hard typdef - proposal - I know it's not in the standard
On Wed, Jan 23, 2013 at 06:53:06AM +, Alec Teal wrote:
> Hello,
>
> This suggestion is obviously about typdefs and discusses a
> *theoretical* implementation, well a few of them. Anyway please do
> read this though. I'm really sorry for the poor structure, my hands
> are really cold and I'm quite tired.
> I understand that this issue has been discussed A LOT and there are
> ways around the limitation, I suspect what I write is nothing new, I
> don't claim to be the first ever.
>
> Why not:
>
> make an "optional keyword", "hard", have a meaning if before
Make your "hard" an attribute of variables:
http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html
Write a plugin http://gcc.gnu.org/onlinedocs/gccint/Plugins.html
or a MELT extension (http://gcc-melt.org/ is a domain specific language to
extend GCC)
dealing with that attribute.
This would be a good way to experiment your idea.
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet 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 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 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)
