Re: Designs for better debug info in GCC
On Jan 1, 2008 12:39 AM, Frank Ch. Eigler <[EMAIL PROTECTED]> wrote: > > "Richard Guenther" <[EMAIL PROTECTED]> writes: > > > [...] I chose to ignore this problem and say we debug the optimized > > program, not the source as far as life ranges are concerned. [...] > > Yes, and this choice has a certain pragmatism. However, it seems to > miss the basic observation that what drives debugging are the > programmer-user's needs, not the compiler-writer's needs. A > programmer-user is primarily interested in his source, and I bet most > would prefer not to think about optimization artifacts at all. It > would be a disservice to amplify the visibility of the latter. While I would generally agree with you, if you look at what debugging information could be retained at higher optimization levels you might want to reconsider. The less optimizations are applied to the program, the closer 'source level debug info' and 'optimized program debug info' are, so I believe this pragmatism is the right thing to do. But of course only real-life testing will tell. Richard.
Re: Status of the DLX backend for GCC?
Hi Nikolaos, On Sun, 30 Dec 2007, [EMAIL PROTECTED] wrote: > Over the previous years, I had downloaded and used both a really archaic > gcc-1.09 DLX backend as well as the one you refer too. They are both in > a sad state of affairs, but the gcc-2.7.2.1 (AFAICR) was usable. do you have a working download location for the latter? Right now, http://www.gnu.org/software/gcc/extensions.html has a broken link and I'd like to address this if possible. > I coded my own DLX backend for GCC. I developed it around > September-October 2006, first for the 3.3.1 release and then updated > its state for the 3.4.4. > [...] > If there is interest, i can submit the backend (where exactly in the > cvs tree?) and with the help of the community can fix the 64-bit moves > issue, plus add soft-floating. I'm not able to approve a change like this (that's left to some others here), but if you'd like to put this up for download somewhere and submit a patch against http://www.gnu.org/software/gcc/extensions.html to give it more exposure, that would a very good first step! For details on how to submit a patch against current GCC sources, our page at http://gcc.gnu.org/contribute.html should provide a good overview. Cheers, Gerald
Optimizations documentation
Hi! I ask you to put optimimizations tips for programmers into your documentation site on www. Sure, there are some texts about program optimimization, but you are the only one, who really understand compilation and execution processes and know how to make program faster. I read on some site that it would better and quicker to use floats instead of doubles, use unsigned int instead of signed as counters in loops, mark const function parameters when they are and so on. Is it true for GCC (G++)? Your compiler makes great optimization, but it'd be better if you explain to programmers how to help to compiler optimize program. For example, some time ago I listened that GCC supports vectorization, but still can't find anything about it, how can I use it in my programs. Your site is the right place for such documentation. PLEASE put it on. Thank you!
Re: Optimizations documentation
Константин wrote: Hi! I ask you to put optimimizations tips for programmers into your documentation site on www. Sure, there are some texts about program optimimization, but you are the only one, who really understand compilation and execution processes and know how to make program faster. I read on some site that it would better and quicker to use floats instead of doubles, use unsigned int instead of signed as counters in loops, mark const function parameters when they are and so on. Is it true for GCC (G++)? Your compiler makes great optimization, but it'd be better if you explain to programmers how to help to compiler optimize program. For example, some time ago I listened that GCC supports vectorization, but still can't find anything about it, how can I use it in my programs. Your site is the right place for such documentation. PLEASE put it on. Thank you! This topic seems more appropriate to the gcc-help mail list. The on-line docs show a fair effort, although documentation of -ftree-vectorize seems difficult to find in a single search: http://gcc.gnu.org/onlinedocs/ Superior performance of float over double is more marked for the SSE platforms, so you should specify your platform of interest when asking such questions. If you want examples, quite a few of those are available on line.
Re: What is a regression?
On Tue, 23 Oct 2007, Mark Mitchell wrote: > [...] I realized that the documentation we currently have up at http://gcc.gnu.org/bugs/management.html was partly incorrect (only listing P1 to P2) and certainly quite incomplete, so I tried to cast my understanding and what I found in this thread into a documentation update. Thoughts on the patch below (which I have not committed yet)? Gerald Index: bugs/management.html === RCS file: /cvs/gcc/wwwdocs/htdocs/bugs/management.html,v retrieving revision 1.25 diff -u -3 -p -r1.25 management.html --- bugs/management.html14 Jan 2007 11:38:36 - 1.25 +++ bugs/management.html1 Jan 2008 21:46:11 - @@ -168,13 +168,37 @@ problem where an easy workaround exists Priority This field describes the importance and order in which a bug should be -fixed. It is utilized by the programmers/engineers to -prioritize their work to be done. The available priorities are: +fixed. The available priorities are: -P1Most important -P2 -P3Least important + + P1 + Most important. This generally labels a regression which the +release manager feels should be addressed for the next release +including wrong-code regressions. +For practical reasons, releases tend to go out with P1 bugs open, +but we try to minimize those. If you want to downgrade a P1 bug, +CC the release manager on the PR and add a note. + + + P2 + This generally indicates a regression users will notice on a +major platform, which is not P1 though. + + + P3 + The default priority for new PRs which have not been prioritized +yet. + + P4 + Usually not a regression, but still of some priority. +ICE-after-valid-error bugs fall in this category, for example, as +do regressions that have persisted for several major releases. + + + P5 + Least important. Not on the radar of release management. +
Re: MPFR 2.3.1 Release Candidate
On Tue, 1 Jan 2008, Vincent Lefevre wrote: > On 2007-12-31 14:38:21 -0500, Kaveh R. GHAZI wrote: > > The bug would need to be exposed using a mantissa size of a C type, like > > 53 for double, and the default exponent range. And all the global mpfr > > flags are cleared beforehand, > > Are they cleared before each call to MPFR functions? Yes I call mpfr_clear_flags() before each mpfr function call. Also, the individual mpfr types are initialized and destroyed for each call, no reuse occurs between different mpfr calls. However... > > I tried several things through gcc+mpfr-2.3.0 like asin(-0.0), but > > that folds to -0.0 correctly. > > Perhaps because the same variable is used for the input and output? Yes, reuse occurs for src and dest variable: mpfr_clear_flags (); inexact = func (m, m, GMP_RNDN); So I guess I got lucky here. :-) > > I tried a call to sqrt(2.0) with -frounding-math. But the inexact > > flag is apparently set and gcc appropriately does not fold this > > case, instead replying on the library call to get the rounding > > correct. > > The ternary value was correct, and I suppose that GCC tests the > ternary value instead of the global inexact flag (this is what one > does in general). Right, as seen above. Later on, I do check the global overflow and underflow flags, but not global inexact. > > Often the bug says it will fail on "huge" inputs, but doesn't say > > exactly what they are. > > Most of the time, testcases were included in the changesets (not > in 53 bits, but in general, this shouldn't matter). You may want > to look at them. I'll poke around some more and see if I can find something. --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Gfortran annual report for 2008
Gfortran maintainers have kept up the momentum of 2006 and the number of known F95 bugs has gone down sharply, the diagnostic capability has increased and new F2003/8 features added. Hopefully, the contributors can continue to move forward with bug fixes, conformance to Fortran 95 standard, and the implementation of Fortran 2003/8 features. However, this needs new blood in the ranks, particularly since Steve Kargl and Bud Davis have hung up their maintainer hats and some of the other regulars are struggling with competition between gfortran and daytime jobs or moves between countries. If you have any interest in helping out, please do not hestitate to contact one of us or to mail the gfortran list, for help on how to get started. An important source of help to us is bug reporting. Best of all is for bugs to be posted in Bugzilla with well reduced testcases. There is a group of regulars out there whose efforts are really appreciated. It is noticable that threads on comp.lang.fortran are becoming increasingly important; particularly to resolve thorny issues of Standard interpretation but also for picking up bugs. A favourite was "Most elegant syntax for inverting a permutation?" which led to corrections of problems with assignment and FORALL. As an aside, it should be noted that the main part of this report was written by Steve Kargl. Many thanks, Steve! Thank you for all your contributions over the years and, should you change your mind, we all look forward to you rejoining us. A few highlights from the past year are: 1) Chris Rickett's ISO C Binding patch. He did ~95% of work with Tobias Burnus, F-X Coudert and Steve Kargl throwing the odd fix here and there. 2) Daniel Franke and Brooks Moses wrote, rewrote, and re-organized large portions of the gfortran manual. This is a thankless task that has resulted in a great improvement to the documentation of gfortran. 3) Brooks and Pault finally implemented TRANSFER(), which was a glaring omission in gfortran's conformance to the F95 standard. 4) Janus Weil was gfortran's first Google SoC student. He worked on the Fortran 2003 PROCEDURE feature. Procedure pointers will be implemented in 2008. 5) An important milestone only a few may notice is that the number of bug reports against conformance to F95 is diminishing. This has been a collective effort with all the maintainers keeping an eye on the "bug-bashing" part of the gfortran wiki, mentioned at the end of this report. 6) Janne Blomqvist finally got his symbol versioning patch into the tree. 7) F-X Coudert, Thomas Koenig, Jerry DeLisle, Janne Blomqvist, and Daniel Franke(and others) have expended a large amount of effort on making libgfortran more robust, faster, cleaner, etc. 8) Subreference array pointers, which was the last missing F95 feature, were implemented by Paul Thomas. This feature permits likes of "my_int_pointer => my_type(:)%int_cmp". 9) At some stage in the year, some underlying bugs were fixed that allowed J.L.Schonfelder's ISO Varying String testsuite to run faultlessly with Rich Townsend's version of the ISV library, which uses allocatable components, aka TR 15581. 10) The backtrace/code-dump option was added by F-X Coudert. 11) The -finit-* options were added by Asher Langton. 12) Although the postion of gfortran in the Polyhedron performance tables has not changed much, the diagnostic rating has creapt up from 34% to 42%. There were 497 commits to the gfortran front-end in 2007. A ChangeLog for a multi-author patch is credited to the first listed name. The number of commits by committer are: Rafael Avila de Espindola 3 Janne Blomqvist 9 Steven Bosscher 1 Paul Brook 2 Tobias Burnus 103 Nick Clifton2 Francois-Xavier Coudert99 Jerry DeLisle 49 Steve Ellcey2 Bernhard Fischer6 Daniel Franke 55 Kaveh R. Ghazi 5 Richard Guenther7 Richard Henderson 1 Aldy Hernandez 1 Kazu Hirata 7 Jan Hubicka 2 Dominique d'Humieres1 Daniel Jacobowitz 1 Jakub Jelinek 11 Steven G. Kargl24 Thomas Koenig 14 Anton Korobeynikov 1 Asher Langton 2 Sandra Loosemore2 Manuel Lopez-Ibanez 1 H.J. Lu 4 Lee Millward4 Mark Mitchell 1 Brooks Moses 50 Dirk Mueller1 Joseph Myers2 Andrew Pinski 3 Christopher D. Rickett 19 Duncan Sands1 Roger Sayle22 Tobias Schlueter 26 Nathan Sidwell 1 Ian Lance Taylor
