dg-extract-results.sh truncates logs containing "Running "
The regex to detect the beginning of a test file execution was too broad, matching any line beginning with "Running ". This caused dg-extract-results.sh to truncate some test logs, including gdb.base/help.exp in the GDB test suite (which tests "help running", printing "Running the program.") The attached patch makes the match a little more precise to avoid this. With this the exact count of PASS/FAIL/etc lines in the dg-extract-results.sh output matches the counts in the computed summary exactly for all cases I've seen. I encountered this in the GDB test suite but was asked to submit the change upstream to GCC as GDB would prefer to avoid unnecessary local changes to the script & this change seems general enough to go in to GCC. I'm still a little fuzzy on the specifics of ChangeLog lines, but here's my attempt at one for this change: * dg-extract-results.sh: constrain the start-of-log pattern to avoid accidentally matching test content extract-running.diff Description: Binary data
Re: dg-extract-results.sh truncates logs containing "Running "
& now with an actual GCC patch, instead of the GDB one - sorry about that. On Tue, Jan 15, 2013 at 8:31 AM, David Blaikie wrote: > The regex to detect the beginning of a test file execution was too > broad, matching any line beginning with "Running ". This caused > dg-extract-results.sh to truncate some test logs, including > gdb.base/help.exp in the GDB test suite (which tests "help running", > printing "Running the program.") > > The attached patch makes the match a little more precise to avoid > this. With this the exact count of PASS/FAIL/etc lines in the > dg-extract-results.sh output matches the counts in the computed > summary exactly for all cases I've seen. > > I encountered this in the GDB test suite but was asked to submit the > change upstream to GCC as GDB would prefer to avoid unnecessary local > changes to the script & this change seems general enough to go in to > GCC. > > I'm still a little fuzzy on the specifics of ChangeLog lines, but > here's my attempt at one for this change: > > * dg-extract-results.sh: constrain the start-of-log pattern to > avoid accidentally matching test content gcc-extract-running.diff Description: Binary data
Fwd: summarize kfails in dg-extract-results.sh
For some reason KFAILs weren't being summarized by dg-extract-results.sh. I assume this was just an oversight, so here's a patch to add it alongside all the other result types. I encountered this in the GDB test suite but was asked to submit the change upstream to GCC as GDB would prefer to avoid unnecessary local changes to the script & this change seems general enough to go in to GCC. (As was pointed out by Pedro Alves on the gdb-patches list, KFAIL support was recently added by Doug Evans ( http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00996.html ), so KPASS support seems like a natural complement) I'm still a little fuzzy on the specifics of ChangeLog lines, but here's my attempt at one for this change: * dg-extract-results.sh: Handle KPASSes. gcc-extract-kpass.diff Description: Binary data
Re: Fwd: summarize kfails in dg-extract-results.sh
On Tue, Jan 15, 2013 at 12:22 PM, Janis Johnson wrote: > On 01/15/2013 09:24 AM, David Blaikie wrote: >> For some reason KFAILs weren't being summarized by >> dg-extract-results.sh. I assume this was just an oversight, so here's >> a patch to add it alongside all the other result types. >> >> I encountered this in the GDB test suite but was asked to submit the >> change upstream to GCC as GDB would prefer to avoid unnecessary local >> changes to the script & this change seems general enough to go in to >> GCC. >> >> (As was pointed out by Pedro Alves on the gdb-patches list, KFAIL >> support was recently added by Doug Evans ( >> http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00996.html ), so KPASS >> support seems like a natural complement) >> >> I'm still a little fuzzy on the specifics of ChangeLog lines, but >> here's my attempt at one for this change: >> >> * dg-extract-results.sh: Handle KPASSes. > > OK. I checked it in. Thanks - though while reviewing this I realize I'd made a mistake (even in such a trivial patch - got muddled up somewhere along the way from GDB 7.5 to GDB ToT to GCC ToT). It was accidentally printing out the kfail count on the kpass line. Fix attached. 2013-01-15 David Blaikie * dg-extract-results.sh: Print KPASS count correctly. gcc-extract-kpass.diff Description: Binary data
Re: [PATCH] Don't make -gsplit-dwarf imply -g
On Tue, Jul 28, 2020, 10:24 PM Fāng-ruì Sòng wrote: > On Thu, May 14, 2020 at 12:16 AM Richard Biener > wrote: > > > > On Wed, May 13, 2020 at 5:50 PM Fangrui Song wrote: > > > > > > On 2020-05-13, Eric Botcazou wrote: > > > >> Did I mention I dislike -fsplit-dwarf? ;) > > > > > > > >Seconded, this will be confusing for almost all users. Since the > option only > > > >affects debug info generation, it should be prefixed with 'g' in any > case. > > > > > > Updating the semantics of -gsplit-dwarf is actually my favorite as > > > well:) > > > > > > -gsplit-dwarf is not common. Many uses have separate -g. Let's change > it. > > > > > > Attached the patch. > > > > OK if there are no objections over the weekend. I guess this change > needs > > documenting in gcc-11/changes.html (which probably does not exist yet, > > will take care of that). > > > > Thanks, > > Richard. > > > > > > > > (I also wish -gdwarf-5 did not imply -g but the ship may have shipped.) > > Richard, are you still going to make this change? > (If you do it, I'll happy to ask folks to move forward with the clang > patch https://reviews.llvm.org/D80391 ) > > I've added a note from the original implementer (Cary Coutant) here: > https://gcc.gnu.org/pipermail/gcc/2020-July/233074.html > > On the clang side, I don't think anyone has expressed that they would > be upset by a behavior change. > I think I've repeatedly expressed this. My concerns are both the break in backwards compatibility and the general direction of -g flags that don't enable debug info emission which at least myself and a couple of other long time dwarf contributors (Eric Christopher and Cary Contant) have been surprised by/not the semantics that many debug info flags have. Several folks have expressed that the semantics are complex, though, > e.g. https://github.com/ccache/ccache/issues/393 >
