Re: Wiki slowness
On Thu, Apr 12, 2012 at 9:10 PM, Diego Novillo wrote: > On 4/12/12 3:00 PM, Jonathan Wakely wrote: >> >> On 12 April 2012 19:53, Jonathan Wakely wrote: >>> >>> Why does saving/editing a page on the GCC wiki take several minutes to >>> reload the page? >> >> >> By several I mean in excess of ten minutes where my browser is still >> spinning saying the page is loading! > > > Yes. I've noticed this for a long time now. I never really bothered > figuring out why. > > My trick is to cancel the transfer and click 'save' again. It then comes > back with the message 'you already saved this page!'. Which I ignore. Heh - that's what I do for years, too ;) I suppose sth crashes on the server side when you save the page, so the communication is broken mid-way. Richard.
Re: Updated GCC vs Clang diagnostics
On 13 April 2012 05:36, Gabriel Dos Reis wrote: > On Thu, Apr 12, 2012 at 9:26 PM, Manuel López-Ibáñez > wrote: > >> I find the color output of Clang just beautiful and, in my opinion, >> color support in GCC would make it a bit more beautiful and attract >> new users, so it is a much better use of developer's time than fixing >> yet another obscure diagnostic issue that only triggers with a careful >> ad-hoc example. That said, I do really think you are free to work on >> what interests you, so I hope to see your patches fixing diagnostics >> issues soon. > > Is this the kind of protracted passive-aggressive opinion you were looking > for? I think my words above should be read in their own context, where their true meaning can be fully appreciated. Then, one may be able to appreciate that: * Saying "I don't think X is important, so I am against it and you should spend your free time in Y." and "Of course, you are free to spend your time in whatever you want." is not logically consistent. The only choices offered are Y or nothing. * A real choice is offered by the paragraph above which changes the statement to "I don't think X is important, and you should use spend your free time on Y, but I am not against Y, so patches welcome." * In the paragraph above, you also seem to have missed the irony that the example I chose as "not important" are small diagnostic issues, on which I (among very very few) have spent significant effort in the recent years. I was hoping that this irony would help the reader to understand that the example is not meant to be taken seriously, and it is only there to demonstrate the previous logical inconsistency. But my writing skills are still as poor as always, since it seems I am having trouble making myself understood by some. So if you still didn't get my point above, I am unable to explain myself in better terms. Thus, let's forget about this and focus on the issue at hand. Cheers, Manuel.
Re: Switch statement case range
On 13 April 2012 00:26, Rick Hodgin wrote: > I was wondering if anyone had a response to this? No one responded on- or > off-list, which was both surprising and confusing. Why? What sort of response were you expecting? What has GCC or GNU got to do with "fraternity between nations, for the abolition or reduction of standing armies and for the holding and promotion of peace congresses"? More to the point, RMS hasn't added code to GCC for many years, it's been the work of lots and lots of others for years. Where's my nobel prize?
Re: Updated GCC vs Clang diagnostics
On Fri, Apr 13, 2012 at 3:27 AM, Manuel López-Ibáñez wrote: > On 13 April 2012 05:36, Gabriel Dos Reis > wrote: >> On Thu, Apr 12, 2012 at 9:26 PM, Manuel López-Ibáñez >> wrote: >> >>> I find the color output of Clang just beautiful and, in my opinion, >>> color support in GCC would make it a bit more beautiful and attract >>> new users, so it is a much better use of developer's time than fixing >>> yet another obscure diagnostic issue that only triggers with a careful >>> ad-hoc example. That said, I do really think you are free to work on >>> what interests you, so I hope to see your patches fixing diagnostics >>> issues soon. >> >> Is this the kind of protracted passive-aggressive opinion you were looking >> for? > > I think my words above should be read in their own context, where > their true meaning can be fully appreciated. Then, one may be able to > appreciate that: > > * Saying "I don't think X is important, so I am against it and you > should spend your free time in Y." and "Of course, you are free to > spend your time in whatever you want." is not logically consistent. > The only choices offered are Y or nothing. > > * A real choice is offered by the paragraph above which changes the > statement to "I don't think X is important, and you should use spend > your free time on Y, but I am not against Y, so patches welcome." > > * In the paragraph above, you also seem to have missed the irony that > the example I chose as "not important" are small diagnostic issues, on > which I (among very very few) have spent significant effort in the > recent years. I was hoping that this irony would help the reader to > understand that the example is not meant to be taken seriously, and it > is only there to demonstrate the previous logical inconsistency. > > But my writing skills are still as poor as always, since it seems I am > having trouble making myself understood by some. So if you still > didn't get my point above, I am unable to explain myself in better > terms. Thus, let's forget about this and focus on the issue at hand. > > Cheers, > > Manuel. If you believe people miss your use of irony, then it is up to you to decide how to effectively get your points through effectively -- I am just not sure blaming people for missing your use of irony is effective. If this passive-aggressive strategy was the first or second time, I would not mind -- in fact, I was hoping you would get tired of it yourself. So, yes just to straight to the points. -- Gaby
Re: Updated GCC vs Clang diagnostics
On 13 April 2012 08:03, Jakub Jelinek wrote: > On Thu, Apr 12, 2012 at 10:11:48PM -0700, Ian Lance Taylor wrote: >> Lawrence Crowl writes: >> >> > On 4/12/12, Manuel López-Ibáñez wrote: >> >> So given your ideal implementation, if the user-visible result >> >> was exactly like the one in Clang, will you be happy with any of >> >> the three things: ranges, color and fix-it hints? >> > >> > There are many issues with color. Does your reader have any >> > color deficiencies? Does your software address them? Does the >> > system software render colors well? Is color contrast sufficient? >> > Is greyscale contrast sufficient? Color is low on my list of >> > desirables. >> >> It would be terrible if an error message could not be understood without >> color. But nobody is suggesting that. >> >> The question at hand is whether color can be used to enhance an error >> message that can be understood without color. For example, whether >> color can be added to current error messages without any other changes. >> >> I personally think it would be an excellent idea. Even clang's C++ >> error messages can be long. A simple use of color is an excellent way >> to draw the eye to the more important parts of the message. If the >> color is not available, then it doesn't help, but the error message can >> be understood without it. > > Yeah, I second this. As Manuel said, we should have an option to select > never/auto/always coloring, colors must be just visual enhancements of the > diagnostics that even when colors are disabled gives all the info that > is needed (highlight error/warning/note diagnostic kind keywords, keywords > in the source, perhaps types, whatever), we should limit to a very small > set of colors, because not so many colors are actually very readable and > perhaps make the color sets configurable somehow (things might be different > if people use normally black characters on white background or white > characters on black background, grep has GREP_COLORS env var here, ls > LS_COLORS). This is exactly what I would like to implement, if I am allowed. But I don't want to turn the diagnostics machinery upside down and implement a "diagnostics internal language" (which I already did in XML http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165#c10, and it sits there useless), just to achieve this. I just want to have a little file called colors.c which abstracts the color implementation including the handling of GCC_COLORS. And add the least amount of code needed to diagnostics.c to check whether the prefix (warning|error|note) should be colored, the caret should be colored, and perhaps the message itself should be colored (or not, once you see the prefix, it is easy to identify the start of messages). That is all that I am proposing. Now, if I can get enough support for this to hope that with a nice implementation it will get accepted, then I will try to get it done. Otherwise, I will just forget about it and enjoy the sun. Cheers, Manuel.
Re: Updated GCC vs Clang diagnostics
On Fri, Apr 13, 2012 at 3:41 AM, Manuel López-Ibáñez wrote: > But I don't want to turn the diagnostics machinery upside down and > implement a "diagnostics internal language" I do think an internal formatting IL/IR for better representation is needed for the kind of things you would like to (e.g. colors) to keep things manageable. That isn't turning things upside down, and it isn't helpful to view it that way. -- Gaby
Re: Updated GCC vs Clang diagnostics
On 13 April 2012 02:40, Joe Buck wrote: > I'm not interested in color output, and would turn it off if it were > implemented (the escape sequences would just mess things up when capturing > compiler output in log files). There's no reason it would have to do that. Git does a great job of colouring output automatically when printing to a terminal but not when redirected to a file or pipe. It also automatically pipes output through a pager when it won't fit on the screen, and because it runs the pager internally it still knows the final output is a terminal and so outputs in colour.
Re: Updated GCC vs Clang diagnostics
On 13 April 2012 10:46, Gabriel Dos Reis wrote: > On Fri, Apr 13, 2012 at 3:41 AM, Manuel López-Ibáñez > wrote: > >> But I don't want to turn the diagnostics machinery upside down and >> implement a "diagnostics internal language" > > I do think an internal formatting IL/IR for better representation is > needed for the > kind of things you would like to (e.g. colors) to keep things manageable. > That isn't turning things upside down, and it isn't helpful to view > it that way. I am not opposed to having a diagnostics IL/IR, so you or anyone else should feel free to start working on it. But after the XML diagnostics experiment, I personally don't find it interesting enough to work on it (specially to start such a project on my own). As a means to get color output, it would be significantly more code, more invasive change, require more time and effort and produce potentially more bugs than the implementation of colors I am proposing above. So I'd rather work on the latter, even if it is much more limited and less flexible than a diagnostics IL. Cheers, Manuel. > > -- Gaby
Re: Updated GCC vs Clang diagnostics
On Fri, Apr 13, 2012 at 3:58 AM, Jonathan Wakely wrote: > On 13 April 2012 02:40, Joe Buck wrote: >> I'm not interested in color output, and would turn it off if it were >> implemented (the escape sequences would just mess things up when capturing >> compiler output in log files). > > There's no reason it would have to do that. Git does a great job of > colouring output automatically when printing to a terminal but not > when redirected to a file or pipe. It also automatically pipes output > through a pager when it won't fit on the screen, and because it runs > the pager internally it still knows the final output is a terminal and > so outputs in colour. Yes, I do not think adding colored output is a challenge when done properly (e.g. checking that, for example, the output device supports ANSI control sequences even when it is a terminal, etc.) What I am concerned about is that the rush to have colored output may shadow the need to do it properly. -- Gaby
Re: Updated GCC vs Clang diagnostics
On 13 April 2012 09:27, Manuel López-Ibáñez wrote: > > I think my words above should be read in their own context, where > their true meaning can be fully appreciated. Then, one may be able to > appreciate that: > > * Saying "I don't think X is important, so I am against it and you > should spend your free time in Y." and "Of course, you are free to > spend your time in whatever you want." is not logically consistent. > The only choices offered are Y or nothing. Joe didn't say *you* should spend your time on Y, he suggested something he thought was more important, and he said *he'd* turn off colour output which is not the same as saying it shouldn't be added. > * A real choice is offered by the paragraph above which changes the > statement to "I don't think X is important, and you should use spend > your free time on Y, but I am not against Y, so patches welcome." That's how I read Joe's mail. There's no reason for this discussion to get heated, we're all working towards the same goal. > * In the paragraph above, you also seem to have missed the irony that > the example I chose as "not important" are small diagnostic issues, on > which I (among very very few) have spent significant effort in the > recent years. I was hoping that this irony would help the reader to > understand that the example is not meant to be taken seriously, and it > is only there to demonstrate the previous logical inconsistency. I'm afraid I missed that irony too, despite being well aware of all the great work you've done on those sort of diagnostics. I was about to reply saying the mixing up "." and "->" is not obscure at all. Irony and subtly don't work by email.
Re: Updated GCC vs Clang diagnostics
On Fri, Apr 13, 2012 at 4:00 AM, Manuel López-Ibáñez wrote: > On 13 April 2012 10:46, Gabriel Dos Reis > wrote: >> On Fri, Apr 13, 2012 at 3:41 AM, Manuel López-Ibáñez >> wrote: >> >>> But I don't want to turn the diagnostics machinery upside down and >>> implement a "diagnostics internal language" >> >> I do think an internal formatting IL/IR for better representation is >> needed for the >> kind of things you would like to (e.g. colors) to keep things manageable. >> That isn't turning things upside down, and it isn't helpful to view >> it that way. > > I am not opposed to having a diagnostics IL/IR, so you or anyone else > should feel free to start working on it. But after the XML diagnostics > experiment, The XML diagnostics experiment was an external representation. > I personally don't find it interesting enough to work on > it (specially to start such a project on my own). As a means to get > color output, it would be significantly more code, more invasive > change, require more time and effort and produce potentially more bugs > than the implementation of colors I am proposing above. So I'd rather > work on the latter, even if it is much more limited and less flexible > than a diagnostics IL. the short term desire to add color should not cloud the architectural concerns. I don't want to get into a situation when in 3 months someone come and complain that the diagnostic code is too obscure or to hard to debug, and when pressed to explain declares that it was just out of frustration or irony -- and even if it was just frustration, that is a concern. -- Gaby
Concurrency items in C++11 status table
The table at http://gcc.gnu.org/projects/cxx0x.html indicates most of the concurrency work is not done, but I think the status is better than it shows. If I'm not mistaken strong CAS and bidirectional fences are done. Does anything need to be done for atomics in signal handlers? at_quick_exit() is available in glibc, is anything needed from GCC? Are any compiler changes needed for sequence points, or is it just a re-wording of existing rules to make sense in a multi-threaded world?
Re: RFC: -Wall by default
On 4/13/2012 2:03 AM, Gabriel Dos Reis wrote: On Thu, Apr 12, 2012 at 4:50 PM, Robert Dewar wrote: End of thread for me, remove me from the reply lists, thanks discussion is going nowhere, at this stage my vote is for no change whatever in the way warnings are handled. I was asked "wassup with Robert?". All I can say s that it is a decade-old relationship :-) -- Gaby Nothing up, just felt nothing more was worth saying on this thread, no point in just getting into the mode of repeating stuff going nowhere.
Re: Updated GCC vs Clang diagnostics
On 13 April 2012 11:04, Gabriel Dos Reis wrote: > On Fri, Apr 13, 2012 at 3:58 AM, Jonathan Wakely > wrote: >> On 13 April 2012 02:40, Joe Buck wrote: >>> I'm not interested in color output, and would turn it off if it were >>> implemented (the escape sequences would just mess things up when capturing >>> compiler output in log files). >> >> There's no reason it would have to do that. Git does a great job of >> colouring output automatically when printing to a terminal but not >> when redirected to a file or pipe. It also automatically pipes output >> through a pager when it won't fit on the screen, and because it runs >> the pager internally it still knows the final output is a terminal and >> so outputs in colour. > > Yes, I do not think adding colored output is a challenge when done properly > (e.g. checking that, for example, the output device supports ANSI control > sequences even when it is a terminal, etc.) What I am concerned about is that > the rush to have colored output may shadow the need to do it properly. If a diagnostics IR is a hard requirement to add color support, then fine. Please, let me know once the diagnostics IR is implemented, and I may consider to try to add color support depending on how complex the IR code is. Please, also let me know if at some moment a simple implementation à la grep becomes acceptable. My excuses to all the readers for such a long thread to reach such a simple conclusion. I also want to apologize to Joe for misunderstanding his position. I don't have anything else to say on this subject. Cheers, Manuel.
Re: Updated GCC vs Clang diagnostics
On Fri, Apr 13, 2012 at 12:53 PM, Manuel López-Ibáñez wrote: > On 13 April 2012 11:04, Gabriel Dos Reis > wrote: >> On Fri, Apr 13, 2012 at 3:58 AM, Jonathan Wakely >> wrote: >>> On 13 April 2012 02:40, Joe Buck wrote: I'm not interested in color output, and would turn it off if it were implemented (the escape sequences would just mess things up when capturing compiler output in log files). >>> >>> There's no reason it would have to do that. Git does a great job of >>> colouring output automatically when printing to a terminal but not >>> when redirected to a file or pipe. It also automatically pipes output >>> through a pager when it won't fit on the screen, and because it runs >>> the pager internally it still knows the final output is a terminal and >>> so outputs in colour. >> >> Yes, I do not think adding colored output is a challenge when done properly >> (e.g. checking that, for example, the output device supports ANSI control >> sequences even when it is a terminal, etc.) What I am concerned about is >> that >> the rush to have colored output may shadow the need to do it properly. > > If a diagnostics IR is a hard requirement to add color support, then > fine. Please, let me know once the diagnostics IR is implemented, and > I may consider to try to add color support depending on how complex > the IR code is. > > Please, also let me know if at some moment a simple implementation à > la grep becomes acceptable. > > My excuses to all the readers for such a long thread to reach such a > simple conclusion. I also want to apologize to Joe for > misunderstanding his position. I don't have anything else to say on > this subject. I suppose we'd want to make the diagnostic machinery accessible by plugins so that IDEs could get an easier hand on things anyway. That way colorization could be achieved using a plugin, too. Richard. > Cheers, > > Manuel.
Re: Concurrency items in C++11 status table
On Fri, 2012-04-13 at 10:46 +0100, Jonathan Wakely wrote: > The table at http://gcc.gnu.org/projects/cxx0x.html indicates most of > the concurrency work is not done, but I think the status is better > than it shows. > > If I'm not mistaken strong CAS and bidirectional fences are done. > > Does anything need to be done for atomics in signal handlers? > > at_quick_exit() is available in glibc, is anything needed from GCC? > > Are any compiler changes needed for sequence points, or is it just a > re-wording of existing rules to make sense in a multi-threaded world? We recently spoke about this: On Thu, 2012-04-12 at 10:15 -0400, Jason Merrill wrote: On 04/11/2012 05:46 PM, Torvald Riegel wrote: > > For the mem model and such yes, but for the following too?: > > - Dynamic initialization and destruction with concurrency > > No. We hold a lock during static local variable initialization, > which > can lead to deadlock. We don't support concurrent initialization or > destruction of objects with unordered initialization. > > > - Thread-local storage > > We have our own version of TLS, but haven't added the standard > version. Jakub pointed out that ctors/dtors for TLS objects could be tricky (when combining with dlopen/dlclose). He further said: So, if the standard allows ctors/dtors for TLS vars, I wonder if it can be supported at all and how. What do others do? Do they just ignore dlclose? Or should we just disable dlclosing of libraries that have constructed such vars, or defer them until there will be just a single thread? > > > - Abandoning a process and at_quick_exit > > No. But Jakub points out glibc having at_quick_exit. > > > - Allow atomics use in signal handlers > > - Sequence points > > I would guess that these don't require any changes, but haven't > verified > this.
Re: Updated GCC vs Clang diagnostics
On Fri, Apr 13, 2012 at 6:36 AM, Richard Guenther wrote: > I suppose we'd want to make the diagnostic machinery accessible by > plugins so that IDEs could get an easier hand on things anyway. That > way colorization could be achieved using a plugin, too. Indeed, we definitely want a standard way to get IDEs communicate with the diagnostic machinery; once that is appreciated, colorization becomes an almost trivial thing to do. -- Gaby
Re: Updated GCC vs Clang diagnostics [Was: Switching to C++ by default in 4.8]
Hello,
Richard Guenther skribis:
> And since yesterday GCC shows
>
> t.C:2:10: error: expected ';' after class definition
> class a {}
> ^
> t.C:6:1: error: expected ';' after struct definition
> }
> ^
>
> as we now enabled -fdiagnostics-show-caret by default.
How important is it to have it enabled by default, since editors/IDEs
would typically jump right at the source location?
Ludo’.
Re: Updated GCC vs Clang diagnostics
On Fri, Apr 13, 2012 at 04:09:19AM -0500, Gabriel Dos Reis wrote: > the short term desire to add color should not cloud the architectural > concerns. > I don't want to get into a situation when in 3 months someone come and > complain > that the diagnostic code is too obscure or to hard to debug, and when pressed > to explain declares that it was just out of frustration or irony -- > and even if it was > just frustration, that is a concern. On the other side, at least for basic color support I see no reason why it would imply the need for any rearchitecturing of the diagnostic machinery. If all we want to initially color is error: in one kind of color, warning: in another one, note: in another one, caret line perhaps some other, then it is just a matter of inserting a few pp_color_switch (pp, COLOR_ERROR); ... pp_color_switch (pp, COLOR_NORMAL);. Or if slightly more is needed, it can be added around some format %letter handlers, say %T could print in some special color if requested. At that point we can have the color support written and if some diagnostic machinery redesign is implemented later, it won't be hard to adjust to it and do more color if desired. Shooting down a potentially user friendly feature to wait until some blue sky redesign is implemented means it might never be implemented. Jakub
Re: Updated GCC vs Clang diagnostics
On Fri, Apr 13, 2012 at 9:23 AM, Jakub Jelinek wrote: > Shooting down a potentially user friendly feature to wait until some blue > sky redesign is implemented means it might never be implemented. This is a mischaracterization and you know it. -- Gaby
Re: Updated GCC vs Clang diagnostics [Was: Switching to C++ by default in 4.8]
On Fri, Apr 13, 2012 at 9:11 AM, Ludovic Courtès
wrote:
> Hello,
>
> Richard Guenther skribis:
>
>> And since yesterday GCC shows
>>
>> t.C:2:10: error: expected ';' after class definition
>> class a {}
>> ^
>> t.C:6:1: error: expected ';' after struct definition
>> }
>> ^
>>
>> as we now enabled -fdiagnostics-show-caret by default.
>
> How important is it to have it enabled by default, since editors/IDEs
> would typically jump right at the source location?
I do not know. Some people ask for it; some people don't want to it.
I personally have no opinion which way should be default.
There is some repeat here. Over 13 years ago, people were screaming
to have line wrapping by default -- because the diagnostic
messages related to templates were just too long and too awful.
I implemented line wrapping for g++ and made it the default. Then people
screamed to take it off, and much of the effort has been essentially
to replace it.
Things evolve and we do expect them to evolve. I would not be surprised
if in 5 years, would scream to have fonts, boxes and glides in diagnostics :-)
-- Gaby
Re: Updated GCC vs Clang diagnostics
On Fri, Apr 13, 2012 at 11:22 AM, Gabriel Dos Reis wrote: > On Fri, Apr 13, 2012 at 9:23 AM, Jakub Jelinek wrote: > >> Shooting down a potentially user friendly feature to wait until some blue >> sky redesign is implemented means it might never be implemented. > > This is a mischaracterization and you know it. > > -- Gaby It is and it isn't. The guy willing to do the basic color stuff has no desire to do what you want. Is there someone else lined up to do it? If not, then forcing a wait on it effectively blocks the available developer.
Re: Updated GCC vs Clang diagnostics
On Fri, Apr 13, 2012 at 10:30 AM, NightStrike wrote: > On Fri, Apr 13, 2012 at 11:22 AM, Gabriel Dos Reis > wrote: >> On Fri, Apr 13, 2012 at 9:23 AM, Jakub Jelinek wrote: >> >>> Shooting down a potentially user friendly feature to wait until some blue >>> sky redesign is implemented means it might never be implemented. >> >> This is a mischaracterization and you know it. >> >> -- Gaby > > It is and it isn't. The guy willing to do the basic color stuff has > no desire to do what you want. Is there someone else lined up to do > it? If not, then forcing a wait on it effectively blocks the > available developer. No. When you submit a patch to GCC (whether it is diagnostics or not is immaterial), you expect that it will get reviewed and recommendations will be made about the appropriate way to get it done. Just have a look at gcc-patches. There is no thing new here. If the submitter refused to follow the recommendations, it is unfair it is being shut down or blocked.
Re: Updated GCC vs Clang diagnostics
On Fri, Apr 13, 2012 at 11:36 AM, Gabriel Dos Reis wrote: > On Fri, Apr 13, 2012 at 10:30 AM, NightStrike wrote: >> On Fri, Apr 13, 2012 at 11:22 AM, Gabriel Dos Reis >> wrote: >>> On Fri, Apr 13, 2012 at 9:23 AM, Jakub Jelinek wrote: >>> Shooting down a potentially user friendly feature to wait until some blue sky redesign is implemented means it might never be implemented. >>> >>> This is a mischaracterization and you know it. >>> >>> -- Gaby >> >> It is and it isn't. The guy willing to do the basic color stuff has >> no desire to do what you want. Is there someone else lined up to do >> it? If not, then forcing a wait on it effectively blocks the >> available developer. > > No. When you submit a patch to GCC (whether it is diagnostics or not > is immaterial), you expect that it will get reviewed and recommendations > will be made about the appropriate way to get it done. Just have a look > at gcc-patches. There is no thing new here. If the submitter > refused to follow the recommendations, it is unfair it is being shut down > or blocked. Be that as it may, at the end of the day, we won't have color gcc if you insist on waiting for the better framework. Unless, of course, you're going to build the better framework. When you're hungry, sometimes it's better to take an offer of an apple when you really want an orange, because otherwise you have nothing.
Re: Updated GCC vs Clang diagnostics
On Fri, Apr 13, 2012 at 10:41 AM, NightStrike wrote: > On Fri, Apr 13, 2012 at 11:36 AM, Gabriel Dos Reis > wrote: >> On Fri, Apr 13, 2012 at 10:30 AM, NightStrike wrote: >>> On Fri, Apr 13, 2012 at 11:22 AM, Gabriel Dos Reis >>> wrote: On Fri, Apr 13, 2012 at 9:23 AM, Jakub Jelinek wrote: > Shooting down a potentially user friendly feature to wait until some blue > sky redesign is implemented means it might never be implemented. This is a mischaracterization and you know it. -- Gaby >>> >>> It is and it isn't. The guy willing to do the basic color stuff has >>> no desire to do what you want. Is there someone else lined up to do >>> it? If not, then forcing a wait on it effectively blocks the >>> available developer. >> >> No. When you submit a patch to GCC (whether it is diagnostics or not >> is immaterial), you expect that it will get reviewed and recommendations >> will be made about the appropriate way to get it done. Just have a look >> at gcc-patches. There is no thing new here. If the submitter >> refused to follow the recommendations, it is unfair it is being shut down >> or blocked. > > Be that as it may, at the end of the day, we won't have color gcc if > you insist on waiting for the better framework. Not necessarily. Would you or Jakub say that he is attempting to shoot down the switch to C++, just because he wants to see some components converted done first (blue sky redesigned done first) even though he did not explicitly offer to do that conversion himself, or would you say that he is making a recommendation of what he considers to be in the best long term interest. I would say the latter. Orange and apple analogy aside. -- Gaby
Re: Switch statement case range
--- On Fri, 4/13/12, Jonathan Wakely wrote: > > I was wondering if anyone had a response to this? No > > one responded on- or off-list, which was both surprising > > and confusing. > Why? What sort of response were you expecting? I didn't have a particular expectation (outside of just some kind of response). :-) > What has GCC or GNU got to do with "fraternity between > nations, for the abolition or reduction of standing armies > and for the holding and promotion of peace congresses"? Well, GCC is part of GNU. GNU is of the Free Software Foundation. The FSF was started by Stallman on principles which were contrary to seemingly fundamental mindsets of the time (and today). His was an ideology organized into a specific thing thta grew into far more than I think even he envisioned. The off-shoots of his creation are powering the world's economy today, powering virtually every machine ever built (at least as an option to do so). Were it not for free software, our world would be markedly different in 2012. Now, specifically to GCC, Linux is built on it. Stallman initially wrote the compiler, debugger, etc., and in so doing got the ball rolling. He's since moved on to the more philosophical end regarding software patents, intellectual property, and the need for free software on principles. He's also devoted his life pretty much exclusively toward this end since 1983/4. > More to the point, RMS hasn't added code to GCC for many years, > it's been the work of lots and lots of others for years. > Where's my nobel prize? Free Software exists as it does today because of Stallman. And I wasn't suggesting RMS get the Nobel Prize for GCC, or even specifically for GNU, but rather for the ideology and philosophical contributions to the world the FSF has created. His initial contributions to all of those (then) fledgling efforts which have panned out into a diverse machine encompassing millions of developers world-wide. Is it not single greatest humanitarian effort begun by a person with an ideological philosophy? His is of such a creation, offered up unto humanity in a way which is unlike other efforts, one where the free labor of literally millions of people across the globe, their skills, their talents, the best they have to offer in many cases, is literally handed over to everyone else for free. And the philosophy behind the GPL ensures that those offerings cannot be retracted at a future date. The Nobel Prize honors people who have changed the world in positive ways, contributing something which makes human life better. RMS has done that with the FSF, GNU in general, and also its offerings (like GCC, surely the fundamental backbone of nearly all free software in existence). I don't think it would be out of line at all to consider the ramifications RMS has had upon this world. He has maintained his vision to free software (and not open source) all along, because he believes and pushes that the right to BE ABLE to share and to have the contributions of your neighbors (both near and far) added to prior work by yourself and others is paramount to having a great society. What better type of improvement is ther than to take the work of millions and offer it for billions to use or improve upon (should they choose)? Name another endeavor piloted by a single individual, especially one which has faced such staunch and continuous opposition at every point, which has then reached such a scope as to touch literally billions of lives, giving every one of them the chance to improve what they have today (should they choose to do so). I'm simply not aware of any efforts of similar scope. Best regards, Rick C. Hodgin
Re: Updated GCC vs Clang diagnostics
On Fri, Apr 13, 2012 at 11:53 AM, Gabriel Dos Reis wrote: > On Fri, Apr 13, 2012 at 10:41 AM, NightStrike wrote: >> On Fri, Apr 13, 2012 at 11:36 AM, Gabriel Dos Reis >> wrote: >>> On Fri, Apr 13, 2012 at 10:30 AM, NightStrike wrote: On Fri, Apr 13, 2012 at 11:22 AM, Gabriel Dos Reis wrote: > On Fri, Apr 13, 2012 at 9:23 AM, Jakub Jelinek wrote: > >> Shooting down a potentially user friendly feature to wait until some blue >> sky redesign is implemented means it might never be implemented. > > This is a mischaracterization and you know it. > > -- Gaby It is and it isn't. The guy willing to do the basic color stuff has no desire to do what you want. Is there someone else lined up to do it? If not, then forcing a wait on it effectively blocks the available developer. >>> >>> No. When you submit a patch to GCC (whether it is diagnostics or not >>> is immaterial), you expect that it will get reviewed and recommendations >>> will be made about the appropriate way to get it done. Just have a look >>> at gcc-patches. There is no thing new here. If the submitter >>> refused to follow the recommendations, it is unfair it is being shut down >>> or blocked. >> >> Be that as it may, at the end of the day, we won't have color gcc if >> you insist on waiting for the better framework. > > Not necessarily. > > Would you or Jakub say that he is attempting to shoot down the switch to C++, > just because he wants to see some components converted done first > (blue sky redesigned done first) even though he did not explicitly offer to > do that conversion himself, or would you say that he is making a > recommendation > of what he considers to be in the best long term interest. I would > say the latter. > Orange and apple analogy aside. > > > -- Gaby Ok, fine, but then explain to me how color gcc happens if nobody wants to do the extra work you want?
Re: Updated GCC vs Clang diagnostics
On Fri, Apr 13, 2012 at 10:59 AM, NightStrike wrote: > On Fri, Apr 13, 2012 at 11:53 AM, Gabriel Dos Reis > wrote: >> On Fri, Apr 13, 2012 at 10:41 AM, NightStrike wrote: >>> On Fri, Apr 13, 2012 at 11:36 AM, Gabriel Dos Reis >>> wrote: On Fri, Apr 13, 2012 at 10:30 AM, NightStrike wrote: > On Fri, Apr 13, 2012 at 11:22 AM, Gabriel Dos Reis > wrote: >> On Fri, Apr 13, 2012 at 9:23 AM, Jakub Jelinek wrote: >> >>> Shooting down a potentially user friendly feature to wait until some >>> blue >>> sky redesign is implemented means it might never be implemented. >> >> This is a mischaracterization and you know it. >> >> -- Gaby > > It is and it isn't. The guy willing to do the basic color stuff has > no desire to do what you want. Is there someone else lined up to do > it? If not, then forcing a wait on it effectively blocks the > available developer. No. When you submit a patch to GCC (whether it is diagnostics or not is immaterial), you expect that it will get reviewed and recommendations will be made about the appropriate way to get it done. Just have a look at gcc-patches. There is no thing new here. If the submitter refused to follow the recommendations, it is unfair it is being shut down or blocked. >>> >>> Be that as it may, at the end of the day, we won't have color gcc if >>> you insist on waiting for the better framework. >> >> Not necessarily. >> >> Would you or Jakub say that he is attempting to shoot down the switch to C++, >> just because he wants to see some components converted done first >> (blue sky redesigned done first) even though he did not explicitly offer to >> do that conversion himself, or would you say that he is making a >> recommendation >> of what he considers to be in the best long term interest. I would >> say the latter. >> Orange and apple analogy aside. >> >> >> -- Gaby > > Ok, fine, but then explain to me how color gcc happens if nobody wants > to do the extra work you want? when you said "Ok, fine", which of the two alternatives did you intend? -- Gaby
Re: Switch statement case range
On 13 April 2012 16:58, Rick Hodgin wrote: > --- On Fri, 4/13/12, Jonathan Wakely wrote: >> > I was wondering if anyone had a response to this? No >> > one responded on- or off-list, which was both surprising >> > and confusing. >> Why? What sort of response were you expecting? > > I didn't have a particular expectation (outside of just some kind of > response). :-) Well, you got one. But much as I like the work of RMS and the FSF, if you just wanted to chat this list isn't the right place for it, this is for discussing development of GCC.
Add __ILP32 and __ILP32__ for X32 programming model
Hi, We need a reliable way to tell if we are compiling for x32 through pre-defined preprocessor symbol. __LP64/__LP64__ aren't specified by x86-64 psABI, although they have been added to GCC 3.3. They can't be counted on to detect x32 since not x86-64 compilers define them. I updated x32 psABI: https://sites.google.com/site/x32abi/documents to define __ILP32 and __ILP32__ for X32 programming model. I will submit a patch for GCC trunk and 4.7 branch. Thanks. -- H.J.
i686-pc-linux-gnu-gcc-4.7.0
$ ./config.guess: i686-pc-linux-gnu $ i686-pc-linux-gnu-gcc-4.7.0 -v Using built-in specs. COLLECT_GCC=i686-pc-linux-gnu-gcc-4.7.0 COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-pc-linux-gnu/4.7.0/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../gcc-4.7.0/configure --disable-checking --enable-languages=c,c++ --enable-multiarch --enable-shared --enable-threads=posix --program-suffix=-4.6 --with-gmp=/usr/local/lib --with-mpc=/usr/lib --with-mpfr=/usr/lib --without-included-gettext --with-system-zlib --with-tune=generic Thread model: posix gcc version 4.7.0 (GCC) $ cat /etc/issue Linux Mint 10 Julia \n \l $ uname -a Linux derivative 2.6.35-31-generic-pae #63-Ubuntu SMP Mon Nov 28 20:48:50 UTC 2011 i686 GNU/Linux libc6 2.12.1-0ubuntu Embedded GNU C Library: Shared libraries
Re: Add __ILP32 and __ILP32__ for X32 programming model
On 04/13/2012 09:18 AM, H.J. Lu wrote: > Hi, > > We need a reliable way to tell if we are compiling for x32 through > pre-defined preprocessor symbol. __LP64/__LP64__ aren't > specified by x86-64 psABI, although they have been added to > GCC 3.3. They can't be counted on to detect x32 since not x86-64 > compilers define them. I updated x32 psABI: > > https://sites.google.com/site/x32abi/documents > > to define __ILP32 and __ILP32__ for X32 programming model. I > will submit a patch for GCC trunk and 4.7 branch. > Can we add __LP64__ to the psABI too? -hpa
Re: Add __ILP32 and __ILP32__ for X32 programming model
On Fri, Apr 13, 2012 at 9:40 AM, H. Peter Anvin wrote: > On 04/13/2012 09:18 AM, H.J. Lu wrote: >> Hi, >> >> We need a reliable way to tell if we are compiling for x32 through >> pre-defined preprocessor symbol. __LP64/__LP64__ aren't >> specified by x86-64 psABI, although they have been added to >> GCC 3.3. They can't be counted on to detect x32 since not x86-64 >> compilers define them. I updated x32 psABI: >> >> https://sites.google.com/site/x32abi/documents >> >> to define __ILP32 and __ILP32__ for X32 programming model. I >> will submit a patch for GCC trunk and 4.7 branch. >> > > Can we add __LP64__ to the psABI too? > X32 psABI has __amd64Defined for both LP64 and X32 programming models. __amd64__ Defined for both LP64 and X32 programming models. __x86_64Defined for both LP64 and X32 programming models. __x86_64__Defined for both LP64 and X32 programming models. __LP64 Defined for LP64 programming model. __LP64__ Defined for LP64 programming model. __ILP32 Defined for X32 programming model. __ILP32__ Defined for X32 programming model. -- H.J.
Add _ILP32 and __ILP32__ for X32 programming model
On Fri, Apr 13, 2012 at 9:44 AM, H.J. Lu wrote: > On Fri, Apr 13, 2012 at 9:40 AM, H. Peter Anvin wrote: >> On 04/13/2012 09:18 AM, H.J. Lu wrote: >>> Hi, >>> >>> We need a reliable way to tell if we are compiling for x32 through >>> pre-defined preprocessor symbol. __LP64/__LP64__ aren't >>> specified by x86-64 psABI, although they have been added to >>> GCC 3.3. They can't be counted on to detect x32 since not x86-64 >>> compilers define them. I updated x32 psABI: >>> >>> https://sites.google.com/site/x32abi/documents >>> >>> to define __ILP32 and __ILP32__ for X32 programming model. I >>> will submit a patch for GCC trunk and 4.7 branch. >>> >> >> Can we add __LP64__ to the psABI too? >> > > X32 psABI has > > __amd64 Defined for both LP64 and X32 programming models. > __amd64__ Defined for both LP64 and X32 programming models. > __x86_64 Defined for both LP64 and X32 programming models. > __x86_64__ Defined for both LP64 and X32 programming models. > __LP64 Defined for LP64 programming model. > __LP64__ Defined for LP64 programming model. > __ILP32 Defined for X32 programming model. > __ILP32__ Defined for X32 programming model. > > It should be _LP64/_ILP32, not __LP64 and __ILP32. I updated x32 psABI. -- H.J.
Character set for libstdc++ manual
Hi! While browsing http://gcc.gnu.org/onlinedocs/libstdc++/ using Firefox, I noticed some mojibake due to the fact that the page was interpreted as iso-8859-15, my default charset, while it is actually meant to be utf-8. The server does not add a charset parameter to its content-type header. Neither does the document contain a corresponding meta tag. The document does contain an xml header, but as the document is shipped as text/html, not application/xhtml+xml, I believe the browser is correct to ignore that. Greetings, Martin von Gagern signature.asc Description: OpenPGP digital signature
Re: Wiki slowness
On Fri, Apr 13, 2012 at 4:04 AM, Richard Guenther wrote: > Heh - that's what I do for years, too ;) I suppose sth crashes on the server > side when you save the page, so the communication is broken mid-way. I haven't looked at this in ages, but for GDB we had a problem with mail notifications being synchronous. The more people were signed up to be notified about changes to the wiki, the slower saves finished. Woe unto you if some of them had down mail servers. -- Thanks, Daniel
Re: Updated GCC vs Clang diagnostics [Was: Switching to C++ by default in 4.8]
On Fri, 2012-04-13 at 10:29 -0500, Gabriel Dos Reis wrote: > There is some repeat here. Over 13 years ago, people were screaming > to have line wrapping by default -- because the diagnostic > messages related to templates were just too long and too awful. > I implemented line wrapping for g++ and made it the default. Then people > screamed to take it off, and much of the effort has been essentially > to replace it. > Things evolve and we do expect them to evolve. I would not be surprised > if in 5 years, would scream to have fonts, boxes and glides in diagnostics > :-) In this case, printing '42' might be good ;) Cheers, Oleg
Re: Wiki slowness
On 13 April 2012 20:28, Daniel Jacobowitz wrote: > On Fri, Apr 13, 2012 at 4:04 AM, Richard Guenther > wrote: >> Heh - that's what I do for years, too ;) I suppose sth crashes on the server >> side when you save the page, so the communication is broken mid-way. > > I haven't looked at this in ages, but for GDB we had a problem with > mail notifications being synchronous. The more people were signed up > to be notified about changes to the wiki, the slower saves finished. > Woe unto you if some of them had down mail servers. Thanks for the clue. I think Tobias Schwinge is the only person who gets notifications from the GCC wiki, but maybe his mail server is the culprit.
Re: Wiki slowness
On 4/13/12 3:37 PM, Jonathan Wakely wrote: Thanks for the clue. I think Tobias Schwinge is the only person who gets notifications from the GCC wiki, but maybe his mail server is the culprit. I generally subscribe to pages I author to watch for spammy edits. Diego.
Re: Wiki slowness
On 13 April 2012 21:20, Diego Novillo wrote: > On 4/13/12 3:37 PM, Jonathan Wakely wrote: > >> Thanks for the clue. I think Tobias Schwinge is the only person who >> gets notifications from the GCC wiki, but maybe his mail server is the >> culprit. > > > I generally subscribe to pages I author to watch for spammy edits. Then I guess I've not edited your pages, only the ones Thomas (not Tobias as I originally wrote, sorry) cares about :)
Re: Updated GCC vs Clang diagnostics
On 4/12/12, Ian Lance Taylor wrote: > Lawrence Crowl writes: > > On 4/12/12, Manuel López-Ibáñez wrote: > > > So given your ideal implementation, if the user-visible > > > result was exactly like the one in Clang, will you be happy > > > with any of the three things: ranges, color and fix-it hints? > > > > There are many issues with color. Does your reader have > > any color deficiencies? Does your software address them? > > Does the system software render colors well? Is color contrast > > sufficient? Is greyscale contrast sufficient? Color is low > > on my list of desirables. > > It would be terrible if an error message could not be understood > without color. But nobody is suggesting that. Agreed, no one is suggesting that. However, without care, the message might be harder to understand _with_ color. At a minimum, one should be able to turn the color off. As I understand it, that option is in the plan. > The question at hand is whether color can be used to enhance an > error message that can be understood without color. For example, > whether color can be added to current error messages without any > other changes. Yes, color can enhance the messages. I don't think we disagree on that. My point was that color is a harder problem that many people understand. For instance, there is no set of colors that meet web contrast standards against both black and white backgrounds. As I understand the plan, the colors will be user-configurable, which goes a long way to addressing the problem because the user can choose colors that work for them. It would be nice if the default configuration worked for a large set of folks. > I personally think it would be an excellent idea. Even clang's C++ > error messages can be long. A simple use of color is an excellent > way to draw the eye to the more important parts of the message. > If the color is not available, then it doesn't help, but the > error message can be understood without it. Let me try to be clear. I have no objection to the work as long as I can turn it off. If the issues I mention above are unaddressed, it is likely that I will turn it off, which is why the feature is low on my list of desirables. If other folks desire it, I'm happy to let them have it. I'm even happy to add an environment variable so that they can have it. But, responding to the survey question, for me color is not a priority. -- Lawrence Crowl
Re: RFC: -Wall by default
On 2012-04-11 01:50, Vincent Lefevre wrote: On 2012-04-09 13:03:38 -0500, Gabriel Dos Reis wrote: On Mon, Apr 9, 2012 at 12:44 PM, Robert Dewar wrote: On 4/9/2012 1:36 PM, Jonathan Wakely wrote: Maybe -Wstandard isn't the best name though, as "standard" usually means something quite specific for compilers, and the warning switch wouldn't have anything to do with standards conformance. -Wdefault might be better except if people want warnings about "defaults" in C++11 (which can mean lot of things). How about a warning level? -W0: no warnings (equivalent to -w) -W1: default -W2: equivalent to the current -Wall -W3: equivalent to the current -Wall -Wextra This is exactly what Microsoft C++ compiler does and what their Visual Studio IDE exposes in the UI. So, there is a reasonable precedent. Oleg.
Re: RFC: -Wall by default
On 12/04/2012 22:36, Gabriel Dos Reis wrote: > On Thu, Apr 12, 2012 at 4:00 PM, Dave Korn wrote: >> On 12/04/2012 16:47, Gabriel Dos Reis wrote: >> >>> I keep talking about useful *warnings*, you keep talking about *numbers*. >> No you don't. You said: >> > People easily associates some ordering to numbers (usually > the greater the better or in this case the worse) which > creates another set of confusion. >> That is talking about numbers. > > And you were complaining about your comments being taken out of context? Yes, I am, because that statement of your above _was_ the context for the whole rest of the discussion. You were interrupting in between me saying "The situation is X" and my next sentence where I continued "Because of Y". *You* were the one who said that the numbers were a problem because people would expect some kind of monotonic increase in warnings related to the numbers, I was the one who pointed out that the suggestion originally offered exactly matched that situation. Seriously, if you think something like this: >> Your argument makes no sense. > > Do you think that assertion makes sens when no evidence is > provided to support it? > >> > You said that there was a problem because >> > people will expect numbered -W options to be ordinal. ... is anything other than a pedantic interruption in the middle of a coherent argument, you have a communication problem. The basic unit of meaning in English is the paragraph, you can't take part of it alone and expect it to make sense out of context, but if you're going to accuse me of doing the same, well, here's your entire original paragraph: > People easily associates some ordering to numbers (usually > the greater the better or in this case the worse) which > creates another set of confusion. Geodelization is great > for machines, hardly so as human interface. There was only one extra sentence in it in the first place, and that other sentence doesn't relate to the first sentence in any way, so I did *not* take your idea out of any kind of context that could in any way have contributed to its coherency. So let's get this silly subthread back on track; here's the summary of where we're at, with all the sidetracks taken out: >>> > -W0: no warnings (equivalent to -w) >>> > -W1: default >>> > -W2: equivalent to the current -Wall >>> > -W3: equivalent to the current -Wall -Wextra >> >> I like this suggestion a lot. > > People easily associates some ordering to numbers (usually > the greater the better or in this case the worse) which > creates another set of confusion. My response to that is that is not a "set of confusion", because there is indeed an ordering to the numbers, with zero being less warnings and 3 being most warnings, and therefore it is not a source of confusion but actually a source of correct knowledge about what the situation actually would be, and therefore that using -W in that way would be a good idea. Now, I admit that I have assumed you meant "source of confusion" rather than "set of confusion", since the latter phrase means nothing in English, so if that's where our misunderstanding has arisen, and you meant something other, then please speak up now and make it clear what you actually meant to convey. cheers, DaveK
Re: RFC: -Wall by default
On 13/04/2012 22:45, Oleg Smolsky wrote: > On 2012-04-11 01:50, Vincent Lefevre wrote: >> On 2012-04-09 13:03:38 -0500, Gabriel Dos Reis wrote: >>> On Mon, Apr 9, 2012 at 12:44 PM, Robert Dewar wrote: On 4/9/2012 1:36 PM, Jonathan Wakely wrote: > Maybe -Wstandard isn't the best name though, as "standard" usually > means something quite specific for compilers, and the warning switch > wouldn't have anything to do with standards conformance. -Wdefault might be better >>> except if people want warnings about "defaults" in C++11 (which can mean >>> lot of things). >> How about a warning level? >> >> -W0: no warnings (equivalent to -w) >> -W1: default >> -W2: equivalent to the current -Wall >> -W3: equivalent to the current -Wall -Wextra >> > This is exactly what Microsoft C++ compiler does and what their Visual > Studio IDE exposes in the UI. So, there is a reasonable precedent. Exactly. Would anyone really think it would be a good idea to just not have the -O levels and expect every end user to mix-and-match from a huge set of somewhat unknown-and-unpredictable-just-from-the-names long and confusingly named individual optimisation suboptions? I think -W levels is a new feature that we can easily retrofit on top of the existing structure without having to break or change anything that already works, and that would be equally as user-friendly and pragmatic as having -O levels has already shown itself to be. cheers, DaveK
Re: RFC: -Wall by default
On 12/04/2012 16:35, Robert Dewar wrote: > On 4/12/2012 10:48 AM, Andrew Haley wrote: > >> Ultimately, it's a matter of taste and experience. I'm going to find >> it hard to write for people who don't know the relative precedence of >> & and | . > > There are probably some programmers who completely know ALL the operator > precedence rules in C. There are probably some subset of those who feel > free to write code that takes full advantage of these rules. I would > hate to read code written by such people :-) I think it's worth suggesting, in the context of this discussion, that one of the main purposes for which warnings exist in the first place is *didactic*: they are very much intended to help teach the inexperienced about the points of the language that they need to get straight in their heads, and that their code /suggests/ that they haven't done so yet. For that reason, I think that it's OK to have false-positive or slightly over-sensitive warnings; certainly you don't want the noise to drown out the signal, but unless they actually really do flood it out then they're not necessarily a terribly bad thing in their own right. cheers, DaveK
gcc-4.6-20120413 is now available
Snapshot gcc-4.6-20120413 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120413/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch revision 186439 You'll find: gcc-4.6-20120413.tar.bz2 Complete GCC MD5=85ffeba2302edf60923280ed2c3bc32e SHA1=3425dae245ce3f45eb868a7f56e5877f876a2fc4 Diffs from 4.6-20120406 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Merging gdc (GNU D Compiler) into gcc
On 11/04/2012 15:12, Iain Buclaw wrote: > This has been rather long wait from my side of the pond (moving has > taken away quite some time from my side). But I'll be in a position > to begin discussion on arrangements this weekend for patches to be > submitted for GCC 4.8. > > I would be grateful if we could start and maintain discussions on > making this happen, and I hope some sort of agreement could be reached > by the end of the month. Well, we're just out of release freeze and back in stage 1, so there should be plenty of time and not too much problem even if it does kick up some issues that need to be dealt with after the fact. What state are your patches in? cheers, DaveK
Re: FW: is "syslimits.h" likely to change?
On 12/04/2012 16:38, Mark Galeck (CW) wrote: > Thank you Ian, hopefully I will be compatible then for a long time, as > Larry Wall would say "at least until the heat death of the Universe". > > I can't "ignore it" :) My build system cannot handle "include_next" - it > cannot handle the situation where you are finding a header file in one -I > directory, and later when you are trying to find it again, you ignore that > directory and find it in a subsequent -I directory. The system is > extremely fast, like a sports car than will only go on asphalt (standard C > and a GCC-like compiler). I'm curious why your build system even needs to handle it? The GCC version of syslimits.h is a private thing, that GCC uses just for its own purposes to adjust or override some of the definitions in the system's native syslimits.h; if you aren't using GCC, then it shouldn't matter, and if you are, then it should be automatic and transparent. And if you're generating dependencies, and using GCC as a compiler, then you should also use "gcc -M" to generate the dependencies, since it'll get them canonically right, rather than any sort of external makedepends utility. So, why does your build system care about it? cheers, DaveK
Re: RFC: -Wall by default
On Fri, Apr 13, 2012 at 5:39 PM, Dave Korn wrote: > On 12/04/2012 22:36, Gabriel Dos Reis wrote: >> On Thu, Apr 12, 2012 at 4:00 PM, Dave Korn wrote: >>> On 12/04/2012 16:47, Gabriel Dos Reis wrote: >>> I keep talking about useful *warnings*, you keep talking about *numbers*. >>> No you don't. You said: >>> >> People easily associates some ordering to numbers (usually >> the greater the better or in this case the worse) which >> creates another set of confusion. >>> That is talking about numbers. >> >> And you were complaining about your comments being taken out of context? > > Yes, I am, because that statement of your above _was_ the context for the > whole rest of the discussion. No, that is not correct. > You were interrupting in between me saying "The > situation is X" and my next sentence where I continued "Because of Y". *You* > were the one who said that the numbers were a problem because people would > expect some kind of monotonic increase in warnings related to the numbers, I > was the one who pointed out that the suggestion originally offered exactly > matched that situation. > > Seriously, if you think something like this: > >>> Your argument makes no sense. >> >> Do you think that assertion makes sens when no evidence is >> provided to support it? >> >>> > You said that there was a problem because >>> > people will expect numbered -W options to be ordinal. > > ... is anything other than a pedantic interruption in the middle of a coherent > argument, you have a communication problem. The basic unit of meaning in > English is the paragraph, you can't take part of it alone and expect it to > make sense out of context, but if you're going to accuse me of doing the same, > well, here's your entire original paragraph: > >> People easily associates some ordering to numbers (usually >> the greater the better or in this case the worse) which >> creates another set of confusion. Geodelization is great >> for machines, hardly so as human interface. > > There was only one extra sentence in it in the first place, and that other > sentence doesn't relate to the first sentence in any way, so I did *not* take > your idea out of any kind of context that could in any way have contributed to > its coherency. Not just because you wanted to make it sound as if it did not have any relation -- so that you can embark on your rhetoric -- means there was no relation. If you want to talk about pedantic interruption, why don't you start with what you see in the mirror? > So let's get this silly subthread back on track; I do not believe you missed any effort to get credit here. > here's the > summary of where we're at, with all the sidetracks taken out: > > -W0: no warnings (equivalent to -w) > -W1: default > -W2: equivalent to the current -Wall > -W3: equivalent to the current -Wall -Wextra >>> >>> I like this suggestion a lot. >> >> People easily associates some ordering to numbers (usually >> the greater the better or in this case the worse) which >> creates another set of confusion. > > My response to that is that is not a "set of confusion", because there is > indeed an ordering to the numbers, with zero being less warnings and 3 being > most warnings, and therefore it is not a source of confusion but actually a > source of correct knowledge about what the situation actually would be, and > therefore that using -W in that way would be a good idea. Now, I > admit that I have assumed you meant "source of confusion" rather than "set of > confusion", since the latter phrase means nothing in English, so if that's > where our misunderstanding has arisen, and you meant something other, then > please speak up now and make it clear what you actually meant to convey. > > cheers, > DaveK >
Re: Switching to C++ by default in 4.8
On 11/04/2012 07:55, Jakub Jelinek wrote: > On Tue, Apr 10, 2012 at 06:35:58PM -0700, Lawrence Crowl wrote: >> The standard says they need not ignore them. >> >> I was thinking more about iterating over the contents. What in the >> current code is an indirect function call inside of a loop becomes >> mostly be inline functions in a C++ iterator style. The loop is now >> fully graspable by the optimizer. > > That comes with its cost though, as we have hundreds of hashtables for > various kinds of types, you'd get hundreds of different instantiations of > the hash table code. hashtab.c is significantly more I-cache friendly > than that. Hmm, is that necessarily the case? GCC is big and I-caches are small; it could well be the case that hashtab.c gets evicted very regularly from the cache, and is only usually constant in it during the course of one individual loop. It wouldn't be any more expensive to map in any one hashtab C++ specialisation vs. another, and they'd all individually be of the same scale as the C hashtab.o code, so unless we have many nested loops that use one kind of hashtab in the outer loop and a different one in the inner loop, we could still end up pretty much where we started from in terms of I-cache usage. I expect profiling would immediately show up whether the two approaches made any significant difference or not, probably very visibly, but I wouldn't dismiss doing the experiment out-of-hand. If the inlining improvements exceed the extra cost of paging, switching to C++ would be justified. cheers, DaveK
Re: Switching to C++ by default in 4.8
On 11/04/2012 22:13, Eric Botcazou wrote: >> So, you only know it's 2 tokens once you know all of tree.def? I'm >> aware that this is just some arbitrary example, but I believe this >> actually strengthens the concern I had. > > Well, if you don't know of FIELD_DECL, you won't go very far, really. > But still, wouldn't it be nice and enhance clarity to be able to use a different character/token between GET and FIELD_DECL than between FIELD and DECL? (Anyway, I still think we should start by just redefining GET_FIELD_DECL et. al. as C++ inline functions - or macros that invoke C++ inline functions, or whatever else that works better for whatever reason, regardless of the implementation details - and let the existing code continue to use them in exactly the same way as before.) cheers, DaveK
Re: Switching to C++ by default in 4.8
On 11/04/2012 13:57, Torvald Riegel wrote: > Please don't dismiss this so easily. Of course this is just an example > and nothing major, but I believe many people will use tab completion on > the shell, for example, and code completion is really similar. On the > shell, or with paths names, you start with typing something, then can > navigate from this context you provided. That just works better when > you say context->function instead of function(context). Say, didn't someone submit a patch at some point to provide a completion-mode for GCC invoked from the command-line? And didn't we (the list) suggest that that would make a lot of sense when combined with the incremental/gccserver branch? Did anything ever happen about that? cheers, DaveK
Re: Switching to C++ by default in 4.8
On 11/04/2012 14:21, Bernd Schmidt wrote: > On 04/11/2012 02:57 PM, Torvald Riegel wrote: >> However, the concern you raised is only one part of the problem. The >> other is that, put in a simplified way, GCC is competing with LLVM about >> new and/or non-fulltime-compiler developers. For me, it looks like LLVM >> is more appealing to them, and I believe part of the reason for that is >> the codebase. > > There seem to be other opinions as well, some voiced in this thread, > which just supports my argument that you can't do it right for everyone. > Part of the reason LLVM is appealing may just be advertising, which we > don't do at all, perhaps due to the deep-seated inferiority complex we > have about gcc. Inferiority complex? I think this thread suggests (and perhaps the -Wall thread too) that we're more in danger of complacently resting on our laurels. We have huge inertia, but just because we've always been the big name in embedded toolkits doesn't mean we always will be. cheers, DaveK
Re: Switching to C++ by default in 4.8
On 11/04/2012 20:30, Tobias Burnus wrote: > In any case, the gfortran front end cannot really afford to loose > developers, given that it is a hobbyist* project and given that > attracting new developers is difficult. > > Tobias > > * In terms of the development; I assume that those who use it for > embedded systems or on the top500 supercomputers, at aircraft > manufactures, weather services or for academic research get paid. ;-) ;-) Maybe you could work together to twist some arms in management? cheers, DaveK
Re: RFC: -Wall by default
On Fri, Apr 13, 2012 at 12:46 PM, Dave Korn wrote: > On 13/04/2012 22:45, Oleg Smolsky wrote: >> On 2012-04-11 01:50, Vincent Lefevre wrote: >>> On 2012-04-09 13:03:38 -0500, Gabriel Dos Reis wrote: On Mon, Apr 9, 2012 at 12:44 PM, Robert Dewar wrote: > On 4/9/2012 1:36 PM, Jonathan Wakely wrote: > >> Maybe -Wstandard isn't the best name though, as "standard" usually >> means something quite specific for compilers, and the warning switch >> wouldn't have anything to do with standards conformance. > -Wdefault > > might be better except if people want warnings about "defaults" in C++11 (which can mean lot of things). >>> How about a warning level? >>> >>> -W0: no warnings (equivalent to -w) >>> -W1: default >>> -W2: equivalent to the current -Wall >>> -W3: equivalent to the current -Wall -Wextra >>> >> This is exactly what Microsoft C++ compiler does and what their Visual >> Studio IDE exposes in the UI. So, there is a reasonable precedent. > > Exactly. Would anyone really think it would be a good idea to just not have > the -O levels and expect every end user to mix-and-match from a huge > set of somewhat unknown-and-unpredictable-just-from-the-names long and > confusingly named individual optimisation suboptions? I think -W levels is a > new feature that we can easily retrofit on top of the existing structure > without having to break or change anything that already works, and that would > be equally as user-friendly and pragmatic as having -O levels has already > shown itself to be. First, I think the -Wn option is fantastic, and I look forward to seeing it. Second, some questions. With -O, it's often said that a given -On level does not correspond to an equivalent list of -f options. I believe even the manual states that for instance -O2 is a bunch of -f's plus some other stuff that you can't turn on without -O2. Would warnings options avoid this? IMO, that's a deficiency in -O, and meta options should be strictly meta. So I guess I'm really asking that the precedent be set that -Wn is always an amalgamation of existing -W options, and that we avoid the -On situation. Can the -Winf option really happen? It should be easy to make that turn on every -W option without having the manually list them and keep it up to date. Like, it should be easy, I would hope, to make that be automatic. Even if just used as a toy, I think this is a neat idea that would not require much work. Would a plugin be able to add in -W's to a given level? So like, I want to use MyPlug, and that comes with it -WMyWarn. I'd like my plugin to be able to say that -W2 turns on -WMyWarn.
Re: RFC: -Wall by default
On Apr 13, 2012, at 5:09 PM, NightStrike wrote: > Can the -Winf option really happen? It should be easy to make that > turn on every -W option without having the manually list them and keep > it up to date. Like, it should be easy, I would hope, to make that be > automatic. Even if just used as a toy, I think this is a neat idea > that would not require much work. Clang has -Weverything, which really does turn on every warning: http://clang.llvm.org/docs/UsersManual.html#diagnostics_enable_everything People who like warnings (and like to know when a new build of the compiler adds something) really like this. OTOH, being able to support this well requires that all warnings have an associated -Wno-XX flag associated with them. -Chris
Abort from expand_gimple_stmt_1 due to gcc_unreacable()
I have been working on a plugin and when I updated to gcc 4.7 I have run into a new issue. The input program is written in go. Anyways, my plugin modifies the function and then gimple_expand_cfg() is called. This typically executes without any issue. However, in one case, gcc now is aborting in expand_gimple_stmt_1(). The gimple stmt that is causing this abort() during the expansion is: "resx 1" and is of gimple type GIMPLE_RESX. I am not sure how to resolve this issue. All of my gimple stmt modifications to this function use gsi_replace() with the update-error-handling flag set to 'true' Any help or suggestions would be much appreciated. Thanks! -Matt
Re: Switching to C++ by default in 4.8
On Thu, Apr 12, 2012 at 6:30 PM, Richard Guenther wrote: > > Yes, files are too big - but splitting them is not easy unless you can > figure out > a hierarchy that you can expose. The largest file is dwarf2out.c with > 22825 lines, > but the average is more like 2000 (just looking at gcc/*.c files). > There are only > 23 files bigger than 6000 lines (out of 356), so the situation is not as bad > as > you paint it. But yes, looking at filenames hardly tells you about its > contents > anymore. > Average file size is not relevant here. You should consider how many code are in files that are big. In gcc/ sub-directory, there are about 600 source files(.c and .h). 63 of them (10%) exceed 100 KB, which contribute over 50% of the total source file size of the directory. 75 of them(13%) is between 50 KB to 100 KB, which contribute 25% of the total source file size of the directory. The rest, 440 or so of them, is below 50 KB, which contribute 75% of the total source file size of the directory. Some of this files are so small that some merging is needed. So, I can say, most of the GCC source code is in large files. And this also hold for language front-ends. -- Chiheng Xu
Re: Switching to C++ by default in 4.8
On Wed, Apr 4, 2012 at 7:38 PM, Richard Guenther wrote: > > Oh, and did we address all the annoyances of debugging gcc when it's > compiled by a C++ compiler? ... > Probably, if you can refrain from using some "advance" C++ features(namespace, template, etc.), you will not have such annoyances. -- Chiheng Xu
Re: Switching to C++ by default in 4.8
On Wed, Apr 4, 2012 at 8:04 PM, Richard Guenther
wrote:
>
> I agree for the idea of converting all of GCC to C++ (whatever that means).
> I disagree for the part making the internal infrastructure easier to use,
> understand and maintain. Which means targeting mostly isolated sub-systems,
> like vec.h (and other various containers), double-int.[ch] (and other various
> way of representing and working with constants). Making tree or gimple a
> C++ class with inheritance and whatever is indeed a huge waste of time
> and existing developer ressources (that, if only because they have to adapt
> and maintain two completely different code-bases over some time).
>
> I expect the GCC core to maintain written in C, compiled by C++.
>
Making tree or gimple or even rtl a C++ class with inheritance should be easy.
Current functions and accessor macros can be preserved.
for example:
C:
typedef struct base_type_tag {
int m_data_1;
} base_type;
typedef struct derived_type_tag {
struct base_type base;
int m_data_2;
} derived_type;
#define BASE_TYPE_ACCESSOR_MACRO_1(a) ...
#define DERIVED_TYPE_ACCESSOR_MACRO_2(a) ...
int base_type _func_1(base_type * p_base, ...)
{
}
int derived_type_func_2(derived_type * p_derived, ...)
{
}
C++:
class base_type {
int m_data_1;
getter_1();
setter_1();
method_1();
};
class derived_type : public base_type {
int m_data_2;
getter_2();
setter_2();
method_2();
};
#define BASE_TYPE_ACCESSOR_MACRO_1(a) ...
#define DERIVED_TYPE_ACCESSOR_MACRO_2(a) ...
int base_type _func_1(base_type * p_base, ...)
{
}
int derived_type_func_2(derived_type * p_derived, ...)
{
}
base_type::getter_1()
{
}
base_type::setter_1()
{
}
base_type::method_1()
{
}
derived_type::getter_2()
{
}
derived_type::setter_2()
{
}
derived_type::method_2()
{
}
--
Chiheng Xu
Re: Switching to C++ by default in 4.8
On Mon, Apr 9, 2012 at 6:40 PM, Richard Guenther
wrote:
>>
>> Certainly there are cases where the type must be made more specific,
>> and getting the wrong type here would necessarily be a dynamic check.
>> However, the number of dynamic checks can be substantially reduced.
>> To provide a specific example, suppose I have a common_decl *p and
>> need to do extra work if it is a var_decl.
>>
>> do_general_work (p);
>> if (var_decl *q = p->to_var ())
>> {
>> do_var_work_1 (q);
>> do_var_work_2 (q);
>> do_var_work_3 (q);
>> do_var_work_4 (q);
>> }
>>
>> The only dynamic work is in the pointer conversion. All other
>> function calls can be statically typed.
>
> Ok. But the above represents a completely different programming
> style than what we use currently. We do
>
> if (is_var_decl (p))
> {
> do_var_work_1 (p);
> ...
> }
>
> so what I was refering to was static errors we get when we are
> able to promote function argument / return types to more specific
> sub-classes.
>
What about this:
if(is_var_decl(p)) {
var_decl * p_var_decl = (var_decl *) p;
do_var_work_1 (p_var_decl);
}else if(is_type_decl(p)){
type_decl * p_type_decl = (type_decl *) p;
do_type_work_2 (p_type_decl);
}else if(is_field_decl(p)){
field_decl * p_field_decl = (field_decl *) p;
do_field_work_3 (p_field_decl);
}
--
Chiheng Xu
Re: Switching to C++ by default in 4.8
On Tue, Apr 10, 2012 at 2:22 AM, Jakub Jelinek wrote: > On Mon, Apr 09, 2012 at 10:55:46AM -0700, Lawrence Crowl wrote: >> A build conversion to C++ is a precondition to any source change >> using C++, though the two could be bundled into one patch. In any >> event, I agree that the conversion needs to provide value. Vectors >> and hash tables are a good early target. > > Hash tables? Ugh, what is wrong with the hash tables we have right now in > GCC? > He probably mean to wrap hash table in C++ class. -- Chiheng Xu
Re: Switching to C++ by default in 4.8
On Tue, Apr 10, 2012 at 4:46 PM, Jakub Jelinek wrote: > On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote: >> Class hierarchy is one such feature that is useful. Assuming we have >> two hierarchies for gcc: one for values rooted at ValExp, and one for >> gimple stmts rooted at GimpInst. >> >> 1) For IR browsing, >> *) all the macro accessors can be eliminated -- a big plus for debugging; > > Not that clear, if all the macros are replaced by tons of inline functions, > the debugging experience can be actually significantly worse. Already some > the > inline functions used like tree_operand_length used by TREE_OPERAND_LENGTH > macro are extremely annoying from debugging POV. > To avoid debugging POV, in the code, a line of code can be used to convert it to the right pointer type and assign it to a temp variable. This line of code can be optimized away, but temp variable of the right pointer type can improve debuggability. >> *) gcc implementation has lots of hard coded TREE_OPERAND (exp, nn) >> >> e.g. >> exp->as_component_ref().get_field() .. >> exp->as_mem_access().get_base() ... >> exp->as_mem_acesss().get_address() --> produces the >> address expression for memory access >> exp->as_mem_access().get_alias_handle () >> >> gimple_inst->serialize (&fixup_list) --> a virtual >> function overriden by actual instruction types that knows its byte >> code format. > > That silently assumes we want to change basic GIMPLE/tree data structures > to virtual classes, which is a significant change that has a significant > cost as well. E.g. all such changed data structures grow by a virtual > pointer field. Those data structures are heavily optimized for memory > footprint. > Not to mention it is very questionable if the above stuff is more readable > than what we currently have. > Agree. -- Chiheng Xu
Re: Switching to C++ by default in 4.8
On Tue, Apr 10, 2012 at 4:46 PM, Jakub Jelinek wrote: > >> *) gcc implementation has lots of hard coded TREE_OPERAND (exp, nn) >> >> e.g. >> exp->as_component_ref().get_field() .. >> exp->as_mem_access().get_base() ... >> exp->as_mem_acesss().get_address() --> produces the >> address expression for memory access >> exp->as_mem_access().get_alias_handle () >> >> gimple_inst->serialize (&fixup_list) --> a virtual >> function overriden by actual instruction types that knows its byte >> code format. > > That silently assumes we want to change basic GIMPLE/tree data structures > to virtual classes, which is a significant change that has a significant > cost as well. E.g. all such changed data structures grow by a virtual > pointer field. Those data structures are heavily optimized for memory > footprint. > Not to mention it is very questionable if the above stuff is more readable > than what we currently have. > And I want to say that tree/gimple/rtl are compiler's data(or state), not compiler's text(or logic), the most important thing about them is how to access their fields. -- Chiheng Xu
Re: Switching to C++ by default in 4.8
On Sat, Apr 14, 2012 at 9:15 AM, Chiheng Xu wrote: > The rest, 440 or so of them, is below 50 KB, which contribute 75% of The rest, 440 or so of them, is below 50 KB, which contribute 25% of -- Chiheng Xu
Re: Updated GCC vs Clang diagnostics
On Fri, 13 Apr 2012, Lawrence Crowl wrote: Yes, color can enhance the messages. I don't think we disagree on that. My point was that color is a harder problem that many people understand. For instance, there is no set of colors that meet web contrast standards against both black and white backgrounds. If we output colored text to a terminal, the colors we will use there are those (usually 8 or 16) set up in the terminal. When you configure your terminal, setting an appropriate color palette is part of it, and when you change the background between light and dark, you also change the palette. Since other applications use colors, I would already be in trouble if they were not readable. So somehow I am not too scared. As I understand the plan, the colors will be user-configurable, which goes a long way to addressing the problem because the user can choose colors that work for them. It would be nice if the default configuration worked for a large set of folks. To confirm your point, clang managed to chose "bold black" as the default color for "note:", which is grey here but still not so visible on my black background :-( With g++ that prints the context of an error first, I often have to carefully scroll many screens of messages until I find the first actual error, so some flashy color there could help. The one thing I have found colors most useful for is coloring types that use a lot of templates. This has become less needed with g++ that uses intermediate types/typedefs to print a short type, but it was a great way to have the arguments at the same depth visible at a glance, and I still use it occasionally (also on the output of c++filt). -- Marc Glisse
