Re: [PATCH] caret diagnostics
Gabriel Dos Reis wrote: On Thu, Aug 14, 2008 at 11:52 AM, Tom Tromey <[EMAIL PROTECTED]> wrote: "Joseph" == Joseph S Myers <[EMAIL PROTECTED]> writes: I'd like to see carets on by default as part of a major release -- say GCC 5.0. (First mention!!) 100% agreed. -- Gaby As I have mentioned before, we have always had very accurate caret diagnostics (though we use | instead of ^ :-)) in GNAT, but decided that brief error messages were the default. 97% of the time, especially for experienced programmers, you really don't need this information, and it is not worth the extra complexity in the output. Furthermore, you certainly don't want this is you are using an IDE which interprets the column numbers in the brief messages and jumps you to the right location anyway (the great majority of Ada users are using an IDE, not all, but certainly most). That's not to say some of our users do not find the caret diagnostics very valuable, and of course thats reasonable as an option, but I wouldn't make it the default. Now one significant difference between Ada and C in the gcc arena is that the messages by default from GNAT always include (highly accurate) column numbers, and that seems desirable anyway, but assuming (I hope I assume right) that the intent of caret diagnostics is to actually post flags in the columns, I don't think that should be the default. One argument in favor of making this the default is that this is the only way to smoke out errors, but I think you could do just as good a job of this by always displaying column numbers and anyway using an IDE, including EMACS (I assume emacs can handle columns fine), will notice problems and can be encouraged to report problems once the messages get good enough to be reasonable. Another interesting capability in GNAT is the -gnatjnn flag which causes a message and its continuation lines to be wrapped together as a single message, and then broken into lines nn long: Consider 1. procedure q is 2.type u8 is range 1 .. 10; 3.a,b : u8 := 10; 4. begin 5.a := b + 1; 6. end; default mode q.adb:5:11: warning: value not in range of type "u8" defined at line 2 q.adb:5:11: warning: "Constraint_Error" will be raised at run time in -gnatv mode: 5.a := b + 1; | >>> warning: value not in range of type "u8" defined at line 2 >>> warning: "Constraint_Error" will be raised at run time in -gnatl mode: 1. procedure q is 2.type u8 is range 1 .. 10; 3.a,b : u8 := 10; 4. begin 5.a := b + 1; | >>> warning: value not in range of type "u8" defined at line 2 >>> warning: "Constraint_Error" will be raised at run time 6. end; default with -gnatj60 q.adb:5:11: warning: value not in range of type "u8" defined at line 2, "Constraint_Error" will be raised at run time -gnatv with -gnatj60 5.a := b + 1; | >>> warning: value not in range of type "u8" defined at line 2, "Constraint_Error" will be raised at run time -gnatl with -gnatj60 1. procedure q is 2.type u8 is range 1 .. 10; 3.a,b : u8 := 10; 4. begin 5.a := b + 1; | >>> warning: value not in range of type "u8" defined at line 2, "Constraint_Error" will be raised at run time 6. end; Another possibility is -gnatjn999 which gathers a message and all its continuation messages in one line, which may be useful in an IDE context where you would like the IDE to format the message (e.g. in a popup box) The one thing that GNAT does not have is a notion of ranges (in the above it would be a little clearer perhaps if the range b+1 were flagged, but in fact given that we are pointing to an overflow, pointing to the operator causing it is worthwhile.
Re: [PATCH] caret diagnostics
Gabriel Dos Reis wrote: I'm in favor of getting -fdiagnostics-show-caret=no by default in this release, and enable people like you to get useful stuff done. That gives us time to iron out outstanding bugs for the next release (and making it the default). That's a good idea regardless of the eventual decision on making it the default.
Re: [PATCH] caret diagnostics
Chris Lattner wrote: On Aug 14, 2008, at 8:47 AM, Joseph S. Myers wrote: On Thu, 14 Aug 2008, Robert Dewar wrote: BTW, I am all in favor of caret output, it's not the default in gnat, the default is more like the C default, but -gnatv gives output like: And I'd hope we could keep things that way for both C and Ada, but make Please don't forget C++. C++ is a completely lost battle. I had a patch to handle all the %s in the source base, but my approach (which basically implied adding translatable strings for "a class", "to a class", "with a class", "in a class", etc. to account for languages with cases) was considered bad. See http://gcc.gnu.org/ml/gcc-patches/2002-06/msg01620.html for my patch. I cannot find the answer. Paolo
Please, do not use the merged revisions log as the commit message when merging
Dear GCC devs, Please do *not* use the full logs of the merged revisions as the commit message of a merge. Apart from making the output of svn log useless, commits messages are parsed are tracked for PR numbers, the commit message is added to the bugzilla page of the PR and people subscribed to the relevant PR in bugzilla are notified of the commit. Therefore a single merge of many revisions would result in a flood of mails sent for no good reason and they make a mess of the bugzilla page. I am sure many of you have been hit by this recently. Please, let's try to avoid this. Thanks, Manuel.
Re: Please, do not use the merged revisions log as the commit message when merging
On Sat, Aug 16, 2008 at 02:35:08PM +0200, Manuel L?pez-Ib??ez wrote: >Dear GCC devs, > >Please do *not* use the full logs of the merged revisions as the >commit message of a merge. Apart from making the output of svn log >useless, commits messages are parsed are tracked for PR numbers, the >commit message is added to the bugzilla page of the PR and people >subscribed to the relevant PR in bugzilla are notified of the commit. >Therefore a single merge of many revisions would result in a flood of >mails sent for no good reason and they make a mess of the bugzilla >page. > >I am sure many of you have been hit by this recently. Please, let's >try to avoid this. If that isn't a good enough reason, doing this completely swamps gcc.gnu.org as it valiantly attempts to send all of the above email. This resulted in a load average of 24 on the system last night and kept me awake until 2:30AM trying to stabilize things. cgf
Re: Please, do not use the merged revisions log as the commit message when merging
2008/8/16 Christopher Faylor <[EMAIL PROTECTED]>: > On Sat, Aug 16, 2008 at 02:35:08PM +0200, Manuel L?pez-Ib??ez wrote: >>Dear GCC devs, >> >>Please do *not* use the full logs of the merged revisions as the >>commit message of a merge. Apart from making the output of svn log >>useless, commits messages are parsed are tracked for PR numbers, the >>commit message is added to the bugzilla page of the PR and people >>subscribed to the relevant PR in bugzilla are notified of the commit. >>Therefore a single merge of many revisions would result in a flood of >>mails sent for no good reason and they make a mess of the bugzilla >>page. >> >>I am sure many of you have been hit by this recently. Please, let's >>try to avoid this. > > If that isn't a good enough reason, doing this completely swamps > gcc.gnu.org as it valiantly attempts to send all of the above email. > This resulted in a load average of 24 on the system last night and kept > me awake until 2:30AM trying to stabilize things. Could we put a limit to the commit log entry? More than 500 hundred lines changelog entries should just be rejected and this will avoid someone accidentally committing a full log or a diff or just random junk. I am willing to try to implement this if I can get access to the pre-commit scripts of our subversion server. I will also propose to reject any attempt to move or delete or rename trunk (this has happened a few times already and it is annoying). I would also propose that we enable revision property modification, so people that have sent a broken commit message are able to fix them[*]. I personally use or grep 'svn log' a lot, and wrong messages are a pain. See the output of svn log -r138275 [*] http://subversion.tigris.org/faq.html#change-log-msg Cheers, Manuel.
Re: [PATCH] caret diagnostics
On Sat, 16 Aug 2008, Paolo Bonzini wrote: > Chris Lattner wrote: > > Please don't forget C++. > > C++ is a completely lost battle. I had a patch to handle all the %s in the > source base, but my approach (which basically implied adding translatable > strings for "a class", "to a class", "with a class", "in a class", etc. to > account for languages with cases) was considered bad. > > See http://gcc.gnu.org/ml/gcc-patches/2002-06/msg01620.html for my patch. I > cannot find the answer. I don't know why it was considered bad (and had thought it was simply never reviewed), but I am happy to review such patches as i18n maintainer (including in Stage 3 - they are clearly bug fixes) if the front-end maintainers don't reject them. However, I think they would need splitting up for review. For example: * Local changes that simply use two or more sentences in a particular place should be separate from more complicated changes like the cp-i18n.c there (but many such local changes could be grouped together). * If passing around an enumeration rather than a sentence fragment, such changes should be split up according to the function whose interface they change. * Where there are relevant bug reports (e.g. 29017 29897 29917 31665 34836) please make sure to include them in the ChangeLog message. * I am not a C++ expert, so if the patch depends on C++ details for which combinations of cases can actually occur and so need messages included then it may still need a C++ maintainer review. I'm not convinced by the cp-i18n.c approach, however, although there may be cases where it's necessary. My preference would be to use full sentences if at all possible (see the WARN_FOR_ASSIGNMENT macro in the C front end and other diagnostics in convert_for_assignment, for example, or readonly_error for another such case). In some cases where this isn't feasible in the source (c_parse_error, format checking - I think all other C cases are fixed) it might be possible for the exgettext script to create all combinations and for full sentences still to be passed for translation -- Joseph S. Myers [EMAIL PROTECTED]
Re: [PATCH] caret diagnostics
I don't know why it was considered bad (and had thought it was simply never reviewed), but I am happy to review such patches as i18n maintainer (including in Stage 3 - they are clearly bug fixes) if the front-end maintainers don't reject them. However, I think they would need splitting up for review. Yes, of course. Unfortunately I don't have much time for submitting patches at all... :-( I'll take note though of your kind offer to review this kind of patch. I'm not convinced by the cp-i18n.c approach, however, although there may be cases where it's necessary. I see. In fact, the main problem was about the cp-i18n.c file in the old review (I *think* by Geoff Keating, but I'm not sure). My preference would be to use full sentences if at all possible (see the WARN_FOR_ASSIGNMENT macro in the C front end and other diagnostics in convert_for_assignment, for example, or readonly_error for another such case). Yes, I know about them. I would also prefer to have full sentences when possible. Paolo
limits.h in gcc 4.3.1 breaks uclibc compilation
Hello, It seems that gcc-4.3.1 has limits.h in the include-fixed directory, instead of the include one. This breaks uclibc compilation. What could be done to fix this? Best regards, Cristi. -- Ing. Cristi Măgherușan, Universitatea Tehnică din Cluj-Napoca Centrul de Comunicații "Pusztai Kalman" Tel. 0264/401247 http://cc.utcluj.ro signature.asc Description: This is a digitally signed message part
Re: limits.h in gcc 4.3.1 breaks uclibc compilation
On Sat, 16 Aug 2008, Cristi Magherusan wrote: > Hello, > > It seems that gcc-4.3.1 has limits.h in the include-fixed directory, > instead of the include one. > This breaks uclibc compilation. > What could be done to fix this? Use uClibc trunk revision 22067 or later. -- Joseph S. Myers [EMAIL PROTECTED]
Re: limits.h in gcc 4.3.1 breaks uclibc compilation
On Sat, 2008-08-16 at 18:21 +, Joseph S. Myers wrote: > On Sat, 16 Aug 2008, Cristi Magherusan wrote: > > > Hello, > > > > It seems that gcc-4.3.1 has limits.h in the include-fixed directory, > > instead of the include one. > > This breaks uclibc compilation. > > What could be done to fix this? > > Use uClibc trunk revision 22067 or later. Yeah, I found the message on their mailing list. Thanks! Best regards, Cristi. -- Ing. Cristi Măgherușan, Universitatea Tehnică din Cluj-Napoca Centrul de Comunicații "Pusztai Kalman" Tel. 0264/401247 http://cc.utcluj.ro
Re: [PATCH][RFT] Optimization pass-pipeline re-organization [3/n]
On Fri, 15 Aug 2008, Richard Guenther wrote: > > This is the third patch in the series of optimizing the pass-pipeline, > it applies on top of [1/n]. Cross-posted again to hint people to test > this on their favorite apps. > > Like moving CCP before the initial alias computation is beneficial this > patch moves the first forwprop pass after alias computation before it. > This again should increase the precision of the first alias pass somewhat. > > The second DCE pass right after FRE is somewhat misplaced > (with the above change we now would run FRE, DCE, copy-prop, > merge-phi, vrp, DCE). copy-prop doesn't benefit from DCE and > while copy-prop exposes DCE opportunities the propagator engine > already removes trivially dead statements. Removing this DCE > pass completely doesn't show any negative effects on tramp3d statistics, > in particular VRP is unaffected. > > > The most interesting pass change is the removal of the first > DOM/phi-cprop pair. DOM mostly deals with jump-threading at this > place and for tramp3d catches 473 threads on top of the 2555 ones > performed by the VRP pass that runs right before the first DOM. > > Thus I took the opportunity to rewrite the CFG walk of VRP and > to properly track SSA name liveness for the edges we insert > asserts on. This removes one of the kludges that disabled > the jump-threading capabilities of VRP in some cases. With > that change the number of jump-threads performed by VRP go up > a bit which compensates for the DOM removal (now the second DOM > pass catches the leftovers instead). > > > The patch has not yet been benchmarked (scheduled for tonight) but > it has been bootstrapped and tested on x86_64-unknown-linux-gnu. SPEC/Polyhedron/C++ tests look good. There is overall improvement in runtime and compile-time. I'll plan to apply this two days after the first patch. Richard.
Re: limits.h in gcc 4.3.1 breaks uclibc compilation
Hello, On Sat, 2008-08-16 at 21:32 +0300, Cristi Magherusan wrote: > On Sat, 2008-08-16 at 18:21 +, Joseph S. Myers wrote: > > On Sat, 16 Aug 2008, Cristi Magherusan wrote: > > > > > Hello, > > > > > > It seems that gcc-4.3.1 has limits.h in the include-fixed directory, > > > instead of the include one. > > > This breaks uclibc compilation. > > > What could be done to fix this? > > > > Use uClibc trunk revision 22067 or later. > > Yeah, I found the message on their mailing list. > Thanks! Okay, That workaround is really working ;) but is this a good fix on the long run? Why wouldn't gcc just let those include files where they belong? Cristi -- Ing. Cristi Măgherușan, Universitatea Tehnică din Cluj-Napoca Centrul de Comunicații "Pusztai Kalman" Tel. 0264/401247 http://cc.utcluj.ro
Re: limits.h in gcc 4.3.1 breaks uclibc compilation
On Sat, Aug 16, 2008 at 5:52 PM, Cristi Magherusan <[EMAIL PROTECTED]> wrote: > Okay, That workaround is really working ;) but is this a good fix on the > long run? Why wouldn't gcc just let those include files where they > belong? limits.h is fixed up header so it belongs in include-fixed. -- Pinski
