public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
To: Mike Stump <mikestump@comcast.net>
Cc: rep.dot.nop@gmail.com, Uros Bizjak <ubizjak@gmail.com>,
	"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH, testsuite]: Cleanup dumps
Date: Mon, 25 Apr 2022 23:34:57 +0200	[thread overview]
Message-ID: <20220425233457.4879165b@nbbrfq> (raw)
In-Reply-To: <CAC1BbcQJWjs+DoYHOrnswrmd=kYwRTGUzr0ktZDJtSRhypwGKQ@mail.gmail.com>

On Fri, 29 May 2015 10:44:02 +0200
Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> wrote:

> On 29 May 2015 at 10:21, Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> wrote:
> > On 31 January 2015 at 22:10, Bernhard Reutner-Fischer
> > <rep.dot.nop@gmail.com> wrote:  
> >> On January 31, 2015 9:17:57 PM GMT+01:00, Mike Stump <mikestump@comcast.net> wrote:  
> 
> >>>If you want to wait until stage 1, that’s fine too.  
> >>
> >> I'd only want that to go in in stage 1.  
> >
> > I have applied this now as r223858.
> > Please CC me on fallout.  
> 
> 
> To recap:
> 
> The idea is to automatically delete dump-files in the testsuite
> instead of annotating alot of testcases in their dg-final.
> 
> To quote sourcebuild.texi, "Clean up generated test files":
> --- 8< ---
> Usually the test-framework removes files that were generated during
> testing. If a testcase, for example, uses any dumping mechanism to
> inspect a passes dump file, the testsuite recognized the dumping option
> passed to the tool and schedules a final cleanup to remove these files.
> --- 8< ---
> 
> The following TCL procs were deleted from the test framework and
> CANNOT be used anymore in dg-final:
> - cleanup-ipa-dump
> - cleanup-rtl-dump
> - cleanup-tree-dump
> - cleanup-saved-temps
> 
> These dump-files are now automatically deleted in the testsuite, via a
> schedule-cleanups in some basic .exp helpers.
> 
> Just delete any // dg-final { cleanup-see-above-list }
> from your new testcases.
> 
> 
> The .plan is to gradually do the same for the remaining dumps like
> stack etc. See remaining parts in sourcebuild.texi and this comment in
> schedule-cleanups:
> +    # TODO
> +    # -fprofile-generate -> cleanup-coverage-files()
> +    # -fstack-usage -> cleanup-stack-usage()
> 
> Mike, just so i do not forget:
> 
> I have retained the cleanup-saved-temps proc for now since it's used in lto.exp.
> I want to rename it later on to prevent people from using it in their
> dg-final since this is now done automatically.
> 
> cheers,

Hi!
Some time later now. We're in gcc-12 stage 4.
The automatic cleanup handling was quite successful i think. I.e. folks
did not have to waste any noteworthy time on manual cleanup hunting ever
since then AFAIK.

So..
Iff you find leftovers in the testsuite in gcc-12 or 11 onwards from
running tests, then please let us know.

And if you are willing to delve into removing the tcl leftovers from
way back, or if you have time to apply some more TLC to the cleanup
handling itself or if you see opportunity to cleanup the cleanup
handling itself, then please do so. IIRC there are a few bits left that
one could handle automatically, if deemed generally useful and if you
have spare time.

PS:
$ git grep dg-final gcc/testsuite/ | egrep -v "(ChangeLog| scan-)" | sed -e 's/.*dg-final //' -e 's/\s*{\s*//' -e 's/}/ /g' | awk '{print $1}' | sort | uniq -c | sort -nr -k1
   2697 check-function-bodies
    486 gdb-test
     62 run-gcov
     34 scan-assembler-times
     25 cleanup-ada-spec
     23 simulate-thread
     22 object-size
...
PS:
gcc/testsuite/lib/scanasm.exp: object-size is under-used.
We should have way more size tests.
And we should have size tests that aim to regain the regressions that
came with the SSA merge ;)

thanks,

  reply	other threads:[~2022-04-25 21:35 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-31 15:38 Uros Bizjak
     [not found] ` <7B4175B2-2FAA-4A96-943B-06B379D03C75@gmail.com>
     [not found]   ` <4420E8FB-D61F-4F61-8A86-6ADE01B235E9@comcast.net>
     [not found]     ` <FFFCE31D-72C2-4542-9A1D-2C67E8DE07D8@gmail.com>
     [not found]       ` <089F97D9-DDFA-420E-8BCA-353F704B0A94@gmail.com>
2015-02-01 17:50         ` Mike Stump
2015-04-23  8:24           ` Bernhard Reutner-Fischer
2015-05-28  9:48             ` [PATCH] auto-wipe dump files, part1, manual stuff Bernhard Reutner-Fischer
2015-05-29  8:44       ` [PATCH, testsuite]: Cleanup dumps Bernhard Reutner-Fischer
2015-05-29 10:08         ` Bernhard Reutner-Fischer
2022-04-25 21:34           ` Bernhard Reutner-Fischer [this message]
2015-05-29 13:33         ` Kyrill Tkachov
2015-05-29 13:38           ` Bernhard Reutner-Fischer
2015-05-29 21:14             ` Christophe Lyon
  -- strict thread matches above, loose matches on Subject: below --
2014-11-04 18:21 Uros Bizjak
2013-12-08 21:47 [PATCH, testsuite ]: " Uros Bizjak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220425233457.4879165b@nbbrfq \
    --to=rep.dot.nop@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=mikestump@comcast.net \
    --cc=ubizjak@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).