Re: Odd performance regression with -Os
Eric Botcazou wrote: >> Thanks. Are you holding this because we're in Stage 3? > > The patch was written very recently so I wanted to let it go through a good > deal of internal testing. Moveover I haven't measured its impact on anything > else than Ada benchmarks (and on a patched 4.3 branch). If people think that > it would be worth having for the 4.4 release, I can port it and conduct basic > testing with it on the mainline, but that's pretty much it. Well, it's a fairly nasty regression on embedded targets with no multiplier, where people are likely to use -Os. Sounds to me like it qualifies for 4.4 Andrew.
Re: GCC 4.4.0 Status Report (2008-11-27)
Am Thu, 27 Nov 2008 18:30:44 + (UTC) schrieb "Joseph S. Myers" : > There are a total of 5150 open bugs in Bugzilla, counting both > regressions and non-regressions. It seems quite likely that many of > the older bugs have in fact been fixed since they were filed, but we > don't have any good procedures for occasionally reviewing bugs to see > if they are still applicable to current trunk. Assuming some random volunteer wants to take a stab at (part of) this, what would (s)he need to do so this is actually useful, and especially how would (s)he best communicate their results? Hmm ... if a useful job description can be made, this could perhaps be added to the newbie project list?
[lto] [RFC] Design proposal for debug support in LTO
LTO currently doesn't support the generation of debug info very well, as we discard much of the front-end information that is needed for debug info before streaming the IR to the intermediate file. I've written up the following proposal to fix this, and have also posted it on the gcc wiki: http://gcc.gnu.org/wiki/LTO_Debug A goal of this design is that it can ultimately enable the use of the free_lang_specifics pass in all compilations, even when not doing LTO. -cary Debug Support for LTO Background With Link-Time Optimization (LTO) enabled, the compiler stores an intermediate representation (IR) of the code in the object file rather than compiled object code (the LGEN phase). The IR is then combined with IR from other object files at link time, and the actual compilation then takes place (the LTRANS phase). This approach naturally divides the compilation process between its front-end and its back-end, and the design of the IR is such that it contains only the language-independent information that would normally be needed by the back-end. In gcc, the symbolic debug information is generated from the tree representation late in the compilation process, and it assumes that all of the original information is still present in the trees. Much of the information that has been discarded in the process of storing the IR at the end of the LGEN phase and reading it back in at the beginning of the LTRANS phase is needed in order to produce the symbolic debug information, even though it is not otherwise needed by the back-end of the compiler. This proposal presents a design for augmenting the IR with the additional information necessary for the generation of symbolic debug information during the LTRANS phase. Alternatives One simple approach is to preserve all of the front-end information in the IR when streaming it to the object files, so that it can all be reconstructed for the LTRANS phase. This approach would significantly increase the size of the IR, so for practical purposes, the compiler would need to arrange to preserve the additional information only when the -g option is used, and the IR for debug and non-debug compilations would differ. This could result in subtle bugs or differences in code generation. In addition, some of the front-end information is language-specific, and since the LTRANS phase may be combining IR from more than one language, langhooks still need to be removed from the back-end. Another approach is to generate the debug information earlier -- in the front-end. This approach would significantly alter the structure of the compiler and would be a major undertaking. In addition, many back-end transformations affect the debug information, so the back-end would then need an infrastructure for decoding the debug information, modifying it, then re-encoding it. Such an approach might be practical for a single debug format, but in order to support the several formats that gcc currently supports, it would also become a major undertaking. An improvement would be to partition the debug information in such a way that the information generated early is not subject to back-end transformations, and that the information preserved for the LTRANS phase is sufficient for generating the remainder of the debug information. In a sense, the design presented here does this, but the early generation does not commit to a specific debug format. Instead, it stores the early information in a higher-level data structure that is written separately to the object file. Overview Near the end of the LGEN phase of the compilation, gcc runs the free_lang_specifics pass, which removes all of the information from the trees that will not be needed by the LTRANS phase. During this pass, just before discarding the information, if debug information has been requested, we will call a new set of debug-related APIs to record debug-related information that is about to be discarded. The debug information for a given tree node will be stored in one of two separate global hash tables (one for decls, one for types), indexed by the UID, as a list of properties. Each separate fact that we need to record will be stored as a property, represented as a (key, value) pair. The property keys are simple small integers that identify the kind of property being recorded (e.g., Context, Base Classes, Member Methods, ...). The property values may be references to another tree, a list of trees, or simple integer or string values. When the IR is streamed out to the object file, we will stream the contents of the debug hash table out to a new section, .gnu.lto_debug. Some of the properties to be streamed out will refer to other trees, some of which may not have been streamed out to the main part of the IR. For references to trees that have already been streamed, we will simply use the "pickle" that was already generated for those trees. For references to trees that were not already streamed out, we will stream those trees out to a seco
Re: GCC 4.4.0 Status Report (2008-11-27)
On Tue, 23 Dec 2008, Kai Henningsen wrote: > Am Thu, 27 Nov 2008 18:30:44 + (UTC) > schrieb "Joseph S. Myers" : > > > There are a total of 5150 open bugs in Bugzilla, counting both > > regressions and non-regressions. It seems quite likely that many of > > the older bugs have in fact been fixed since they were filed, but we > > don't have any good procedures for occasionally reviewing bugs to see > > if they are still applicable to current trunk. > > Assuming some random volunteer wants to take a stab at (part of) this, > what would (s)he need to do so this is actually useful, and especially > how would (s)he best communicate their results? There's a "Last confirmed" field in our Bugzilla, so selecting "Reconfirm bug" is useful whenever you have indeed managed to confirm the bug. Similarly, updating "Known to work" and "Known to fail" is useful. Obvious things to consider: can you reproduce the bug with trunk and confirm that it is indeed a bug? If so, update those fields, and move from UNCONFIRMED to NEW if still in UNCONFIRMED. If a regression, add the regression marker in the summary and set the milestone. If it's an old bug you can't confirm because you don't have the target, ask the submitter to reconfirm (and put in WAITING). If it's been in WAITING a long time without feedback (see "View Bug Activity") then close for lack of feedback. "bootstrap" bugs especially need reconfirmation after a while. For bugs reported for testcase failures, gcc-testresults may be helpful (but watch out for the tests having been XFAILed rather than fixed - bugs associated with XFAILed failures should remain open until the problem is actually fixed). Consider whether the bug is in the right component. Components such as "c" and "c++" should be for bugs in those front ends, not for bugs in other parts of the compiler with testcases in those languages. "regression" is for automatic regression tester reports that need filing manually in another component. Some bug reports may not in fact reflect any GCC bug and so should be closed as invalid, or may have too little information to tell whether there is a bug in which case they need to go in WAITING with a request for that information. If the bug appears only to apply for a target that's now been removed, it may be possible to close it. If the bug is a duplicate of one you reviewed earlier, you can mark it as such. If you and the original submitter can no longer reproduce a bug, closing it as fixed will generally be appropriate unless there is reason to believe that the underlying problem is still present and the bug has just gone latent. Identifying the fix may of course be useful and make certain that the bug can be closed. If the bug has been in ASSIGNED for a long time, ask if the person assigned is actually working on it - if they aren't working on it any more, they should be unassigned. In general, anything that's appropriate when reviewing bugs just after they come in is appropriate in reviewing old bugs, but it's also likely there are a fair number of bugs that were quietly fixed by someone who didn't know about the bug report in question. If a bug is very easy to fix, fixing it would be great. If there's a patch attached by an unknown person, they should be pointed at the instructions for contributing. If a patch was submitted to gcc-patches and not reviewed, asking the submitter to ping it or retesting and pinging it yourself may be good. I think going through bugs by component would be a reasonable approach to this. -- Joseph S. Myers jos...@codesourcery.com
