diff mbox

[testsuite] : Cleanup dumps

Message ID CAFULd4Z=DM4GwUfBJVugNXsm0XM6-9eB5cwH0gxOwC+QKtQ7sg@mail.gmail.com
State New
Headers show

Commit Message

Uros Bizjak Jan. 31, 2015, 9:53 a.m. UTC
Hello!

2015-01-31  Uros Bizjak  <ubizjak@gmail.com>

    * g++.dg/ipa/pr64146.C (dg-final): Cleanup icf ipa dump.
    * gcc.target/i386/chkp-builtins-1.c (dg-final): Cleanup chkp tree dump.
    * gcc.target/i386/chkp-builtins-2.c (dg-final): Ditto.
    * gcc.target/i386/chkp-builtins-3.c (dg-final): Ditto.
    * gcc.target/i386/chkp-builtins-4.c (dg-final): Ditto.
    * gcc.target/i386/chkp-const-check-1.c (dg-final): Cleanup chkopt
    tree dump.
    * gcc.target/i386/chkp-lifetime-1.c (dg-final): Ditto.
    * gcc.target/i386/chkp-remove-bndint-1.c (dg-final): Cleanup optimized
    tree dump.
    * gcc.target/i386/chkp-remove-bndint-2.c (dg-final): Ditto.
    * gfortran.dg/goacc/private-1.f95 (dg-final): Cleanup omplower
    tree dump.

Tested on x86_64-linux-gnu {,-m32} and committed to mainline SVN.

Uros.

Comments

Bernhard Reutner-Fischer Jan. 31, 2015, 7:50 p.m. UTC | #1
On January 31, 2015 10:53:39 AM GMT+01:00, Uros Bizjak <ubizjak@gmail.com> wrote:
>Hello!

Reminds me of just auto-wiping dump files:
https://gcc.gnu.org/ml/gcc-patches/2013-10/msg02506.html

Mike, WDYT?

Thanks,
>
>2015-01-31  Uros Bizjak  <ubizjak@gmail.com>
>
>    * g++.dg/ipa/pr64146.C (dg-final): Cleanup icf ipa dump.
>* gcc.target/i386/chkp-builtins-1.c (dg-final): Cleanup chkp tree dump.
>    * gcc.target/i386/chkp-builtins-2.c (dg-final): Ditto.
>    * gcc.target/i386/chkp-builtins-3.c (dg-final): Ditto.
>    * gcc.target/i386/chkp-builtins-4.c (dg-final): Ditto.
>    * gcc.target/i386/chkp-const-check-1.c (dg-final): Cleanup chkopt
>    tree dump.
>    * gcc.target/i386/chkp-lifetime-1.c (dg-final): Ditto.
> * gcc.target/i386/chkp-remove-bndint-1.c (dg-final): Cleanup optimized
>    tree dump.
>    * gcc.target/i386/chkp-remove-bndint-2.c (dg-final): Ditto.
>    * gfortran.dg/goacc/private-1.f95 (dg-final): Cleanup omplower
>    tree dump.
>
>Tested on x86_64-linux-gnu {,-m32} and committed to mainline SVN.
>
>Uros.
Mike Stump Jan. 31, 2015, 8:17 p.m. UTC | #2
On Jan 31, 2015, at 11:50 AM, Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> wrote:
> On January 31, 2015 10:53:39 AM GMT+01:00, Uros Bizjak <ubizjak@gmail.com> wrote:
>> Hello!
> 
> Reminds me of just auto-wiping dump files:
> https://gcc.gnu.org/ml/gcc-patches/2013-10/msg02506.html

> Mike, WDYT?

Ok.

My only concern of speed isn’t founded, as you stated it was faster to scan the flags.

I think I’m fine with it going in now, but, if you do, you have to watch for and resolve any fallout.  Watch for RM comments, I’d defer to them on timing.

If you want to wait until stage 1, that’s fine too.
Bernhard Reutner-Fischer Jan. 31, 2015, 9:10 p.m. UTC | #3
On January 31, 2015 9:17:57 PM GMT+01:00, Mike Stump <mikestump@comcast.net> wrote:
>On Jan 31, 2015, at 11:50 AM, Bernhard Reutner-Fischer
><rep.dot.nop@gmail.com> wrote:
>> On January 31, 2015 10:53:39 AM GMT+01:00, Uros Bizjak
><ubizjak@gmail.com> wrote:
>>> Hello!
>> 
>> Reminds me of just auto-wiping dump files:
>> https://gcc.gnu.org/ml/gcc-patches/2013-10/msg02506.html
>
>> Mike, WDYT?
>
>Ok.
>
>My only concern of speed isn’t founded, as you stated it was faster to
>scan the flags.
>
>I think I’m fine with it going in now, but, if you do, you have to
>watch for and resolve any fallout.  Watch for RM comments, I’d defer to
>them on timing.
>
>If you want to wait until stage 1, that’s fine too.

I'd only want that to go in in stage 1.

Thanks,
Bernhard Reutner-Fischer Jan. 31, 2015, 9:55 p.m. UTC | #4
On January 31, 2015 10:10:27 PM GMT+01:00, 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:
>>On Jan 31, 2015, at 11:50 AM, Bernhard Reutner-Fischer
>><rep.dot.nop@gmail.com> wrote:
>>> On January 31, 2015 10:53:39 AM GMT+01:00, Uros Bizjak
>><ubizjak@gmail.com> wrote:
>>>> Hello!
>>> 
>>> Reminds me of just auto-wiping dump files:
>>> https://gcc.gnu.org/ml/gcc-patches/2013-10/msg02506.html
>>
>>> Mike, WDYT?
>>
>>Ok.
>>
>>My only concern of speed isn’t founded, as you stated it was faster to
>>scan the flags.

What about the -Wcomment question?
And can you help with the two ??? maybe?

Thanks,
>>
>>I think I’m fine with it going in now, but, if you do, you have to
>>watch for and resolve any fallout.  Watch for RM comments, I’d defer
>to
>>them on timing.
>>
>>If you want to wait until stage 1, that’s fine too.
>
>I'd only want that to go in in stage 1.
>
>Thanks,
Mike Stump Feb. 1, 2015, 5:49 p.m. UTC | #5
On Jan 31, 2015, at 1:55 PM, Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> wrote:
> 
> What about the -Wcomment question?

I don’t consider it linked in anyway to the patch at hand.  I’m not a big fan of the default flags being much different than the flags the user normally sees.  That said, would be nice to avoid this issue.  The best way forward I can think of would be a wholesale change to // style comments in the test suite for all test cases that accept that language.  // is standard C and C++, and by convention, I think they are fine in Objective-C and Obective-C++.

> And can you help with the two ??? maybe?

Which type of help?
Bernhard Reutner-Fischer April 23, 2015, 8:24 a.m. UTC | #6
On 1 February 2015 at 18:49, Mike Stump <mikestump@comcast.net> wrote:
> On Jan 31, 2015, at 1:55 PM, Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> wrote:
>>
>> What about the -Wcomment question?
>
> I don’t consider it linked in anyway to the patch at hand.  I’m not a big fan of the default flags being much different than the flags the user normally sees.  That said, would be nice to avoid this issue.  The best way forward I can think of would be a wholesale change to // style comments in the test suite for all test cases that accept that language.  // is standard C and C++, and by convention, I think they are fine in Objective-C and Obective-C++.

I won't do a wholesale change to C++-style comments in the testsuite
(where applicable),
that's too time-consuming.

Since you OKed the patch cited below, i suggest i apply those hunks of
the manual patch that are still relevant since i think they make sense
regardless of the auto-wipe dumpfiles stuff going in or not.

>
>> And can you help with the two ??? maybe?
>
> Which type of help?

In the last posted patch
https://gcc.gnu.org/ml/gcc-patches/2013-12/msg01749.html
there is only one question left:
+    foreach src $testcases {
+ set basename [file tail $src]
+ if { $ltrans != "" } {
+    # ??? should we use upvar 1 output_file instead of this (dup ?)
+    set stem [file rootname $basename]
+    set basename_ext [file extension $basename]
+    if {$basename_ext != ""} {
+ regsub -- {^.*\.} $basename_ext {} basename_ext
+    }
+    lappend tfiles "$stem.{$basename_ext,exe}"
+    unset basename_ext
+ } else {
+    lappend tfiles $basename
+ }
+    }

I wasn't sure if upvar 1 output_file would globally work? WDYT?

PS: IIRC someone from codesourcery meanwhile fixed the pch test
objects leftovers
so the
* lib/dg-pch.exp(pch-init): Remove pch-check objects.
is obsolete by now.
Bernhard Reutner-Fischer May 29, 2015, 8:21 a.m. UTC | #7
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:
>>On Jan 31, 2015, at 11:50 AM, Bernhard Reutner-Fischer
>><rep.dot.nop@gmail.com> wrote:
>>> On January 31, 2015 10:53:39 AM GMT+01:00, Uros Bizjak
>><ubizjak@gmail.com> wrote:
>>>> Hello!
>>>
>>> Reminds me of just auto-wiping dump files:
>>> https://gcc.gnu.org/ml/gcc-patches/2013-10/msg02506.html
>>
>>> Mike, WDYT?
>>
>>Ok.
>>
>>My only concern of speed isn’t founded, as you stated it was faster to
>>scan the flags.
>>
>>I think I’m fine with it going in now, but, if you do, you have to
>>watch for and resolve any fallout.  Watch for RM comments, I’d defer to
>>them on timing.
>>
>>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.

Thanks,
Bernhard Reutner-Fischer May 29, 2015, 8:44 a.m. UTC | #8
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,
Bernhard Reutner-Fischer April 25, 2022, 9:34 p.m. UTC | #9
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,
diff mbox

Patch

Index: g++.dg/ipa/pr64146.C
===================================================================
--- g++.dg/ipa/pr64146.C	(revision 220302)
+++ g++.dg/ipa/pr64146.C	(working copy)
@@ -36,3 +36,4 @@ 
 
 /* { dg-final { scan-ipa-dump-times "Declaration does not bind to currect definition." 2 "icf"  } } */
 /* { dg-final { scan-ipa-dump "Equal symbols: 2" "icf"  } } */
+/* { dg-final { cleanup-ipa-dump "icf" } } */
Index: gcc.target/i386/chkp-builtins-1.c
===================================================================
--- gcc.target/i386/chkp-builtins-1.c	(revision 220302)
+++ gcc.target/i386/chkp-builtins-1.c	(working copy)
@@ -2,6 +2,7 @@ 
 /* { dg-require-effective-target mpx } */
 /* { dg-options "-fcheck-pointer-bounds -mmpx -fdump-tree-chkp" } */
 /* { dg-final { scan-tree-dump-not "bnd_init_ptr_bounds" "chkp" } } */
+/* { dg-final { cleanup-tree-dump "chkp" } } */
 
 void *
 chkp_test (void *p)
Index: gcc.target/i386/chkp-builtins-2.c
===================================================================
--- gcc.target/i386/chkp-builtins-2.c	(revision 220302)
+++ gcc.target/i386/chkp-builtins-2.c	(working copy)
@@ -2,6 +2,7 @@ 
 /* { dg-require-effective-target mpx } */
 /* { dg-options "-fcheck-pointer-bounds -mmpx -fdump-tree-chkp" } */
 /* { dg-final { scan-tree-dump-not "bnd_copy_ptr_bounds" "chkp" } } */
+/* { dg-final { cleanup-tree-dump "chkp" } } */
 
 void *
 chkp_test (void *p, void *q)
Index: gcc.target/i386/chkp-builtins-3.c
===================================================================
--- gcc.target/i386/chkp-builtins-3.c	(revision 220302)
+++ gcc.target/i386/chkp-builtins-3.c	(working copy)
@@ -2,6 +2,7 @@ 
 /* { dg-require-effective-target mpx } */
 /* { dg-options "-fcheck-pointer-bounds -mmpx -fdump-tree-chkp" } */
 /* { dg-final { scan-tree-dump-not "bnd_set_ptr_bounds" "chkp" } } */
+/* { dg-final { cleanup-tree-dump "chkp" } } */
 
 void *
 chkp_test (void *p)
Index: gcc.target/i386/chkp-builtins-4.c
===================================================================
--- gcc.target/i386/chkp-builtins-4.c	(revision 220302)
+++ gcc.target/i386/chkp-builtins-4.c	(working copy)
@@ -2,6 +2,7 @@ 
 /* { dg-require-effective-target mpx } */
 /* { dg-options "-fcheck-pointer-bounds -mmpx -fdump-tree-chkp" } */
 /* { dg-final { scan-tree-dump-not "bnd_null_ptr_bounds" "chkp" } } */
+/* { dg-final { cleanup-tree-dump "chkp" } } */
 
 void *
 chkp_test (void *p)
Index: gcc.target/i386/chkp-const-check-1.c
===================================================================
--- gcc.target/i386/chkp-const-check-1.c	(revision 220302)
+++ gcc.target/i386/chkp-const-check-1.c	(working copy)
@@ -3,8 +3,8 @@ 
 /* { dg-options "-fcheck-pointer-bounds -mmpx -O2 -fdump-tree-chkpopt" } */
 /* { dg-final { scan-tree-dump-not "bndcl" "chkpopt" } } */
 /* { dg-final { scan-tree-dump-not "bndcu" "chkpopt" } } */
+/* { dg-final { cleanup-tree-dump "chkpopt" } } */
 
-
 int test (int *p)
 {
   p = (int *)__builtin___bnd_set_ptr_bounds (p, sizeof (int));
Index: gcc.target/i386/chkp-lifetime-1.c
===================================================================
--- gcc.target/i386/chkp-lifetime-1.c	(revision 220302)
+++ gcc.target/i386/chkp-lifetime-1.c	(working copy)
@@ -2,6 +2,7 @@ 
 /* { dg-require-effective-target mpx } */
 /* { dg-options "-fcheck-pointer-bounds -mmpx -O2 -fdump-tree-chkpopt-details" } */
 /* { dg-final { scan-tree-dump "Moving creation of \[^ \]+ down to its use" "chkpopt" } } */
+/* { dg-final { cleanup-tree-dump "chkpopt" } } */
 
 extern int arr[];
 
Index: gcc.target/i386/chkp-remove-bndint-1.c
===================================================================
--- gcc.target/i386/chkp-remove-bndint-1.c	(revision 220302)
+++ gcc.target/i386/chkp-remove-bndint-1.c	(working copy)
@@ -2,8 +2,8 @@ 
 /* { dg-require-effective-target mpx } */
 /* { dg-options "-fcheck-pointer-bounds -mmpx -O2 -fdump-tree-optimized" } */
 /* { dg-final { scan-tree-dump-not "bndint" "optimized" } } */
+/* { dg-final { cleanup-tree-dump "optimized" } } */
 
-
 struct S
 {
   int a;
Index: gcc.target/i386/chkp-remove-bndint-2.c
===================================================================
--- gcc.target/i386/chkp-remove-bndint-2.c	(revision 220302)
+++ gcc.target/i386/chkp-remove-bndint-2.c	(working copy)
@@ -2,8 +2,8 @@ 
 /* { dg-require-effective-target mpx } */
 /* { dg-options "-fcheck-pointer-bounds -mmpx -O2 -fdump-tree-optimized -Wchkp" } */
 /* { dg-final { scan-tree-dump-not "bndint" "optimized" } } */
+/* { dg-final { cleanup-tree-dump "optimized" } } */
 
-
 struct S
 {
   int a;
Index: gfortran.dg/goacc/private-1.f95
===================================================================
--- gfortran.dg/goacc/private-1.f95	(revision 220302)
+++ gfortran.dg/goacc/private-1.f95	(working copy)
@@ -35,3 +35,4 @@ 
 ! { dg-final { scan-tree-dump-times "private\\(i\\)" 3 "omplower" } }
 ! { dg-final { scan-tree-dump-times "private\\(j\\)" 2 "omplower" } }
 ! { dg-final { scan-tree-dump-times "private\\(k\\)" 1 "omplower" } }
+! { dg-final { cleanup-tree-dump "omplower" } }