Patchwork [testsuite] remove XFAIL for all but ia64 for g++.dg/tree-ssa/pr43411.C

login
register
mail settings
Submitter Janis Johnson
Date May 24, 2011, 7:23 p.m.
Message ID <4DDC05B3.2070007@codesourcery.com>
Download mbox | patch
Permalink /patch/97207/
State New
Headers show

Comments

Janis Johnson - May 24, 2011, 7:23 p.m.
Archived test results for 4.7.0 for most processors with C++ results have:

XPASS: g++.dg/tree-ssa/pr43411.C scan-tree-dump-not optimized "OBJ_TYPE_REF"

The only failures I could find were for ia64-linux and ia64-hpux.  This
patch changes the xfail so it only applies to ia64-*-*.  OK for trunk?
2011-05-24  Janis Johnson  <janisjo@codesourcery.com>

	* g++.dg/tree-ssa/pr43411.C: Limit xfail to ia64.
Mike Stump - May 25, 2011, 12:24 a.m.
On May 24, 2011, at 12:23 PM, Janis Johnson wrote:
> Archived test results for 4.7.0 for most processors with C++ results have:
> 
> XPASS: g++.dg/tree-ssa/pr43411.C scan-tree-dump-not optimized "OBJ_TYPE_REF"
> 
> The only failures I could find were for ia64-linux and ia64-hpux.  This
> patch changes the xfail so it only applies to ia64-*-*.  OK for trunk?

Ok.
Rainer Orth - May 25, 2011, 8:38 a.m.
Janis Johnson <janisjo@codesourcery.com> writes:

> Archived test results for 4.7.0 for most processors with C++ results have:
>
> XPASS: g++.dg/tree-ssa/pr43411.C scan-tree-dump-not optimized "OBJ_TYPE_REF"
>
> The only failures I could find were for ia64-linux and ia64-hpux.  This
> patch changes the xfail so it only applies to ia64-*-*.  OK for trunk?

Richard rejected a similar patch:

	http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00054.html

Perhaps Jan can suggest the correct approach?

	Rainer
Richard Guenther - May 25, 2011, 9:04 a.m.
On Wed, May 25, 2011 at 10:38 AM, Rainer Orth
<ro@cebitec.uni-bielefeld.de> wrote:
> Janis Johnson <janisjo@codesourcery.com> writes:
>
>> Archived test results for 4.7.0 for most processors with C++ results have:
>>
>> XPASS: g++.dg/tree-ssa/pr43411.C scan-tree-dump-not optimized "OBJ_TYPE_REF"
>>
>> The only failures I could find were for ia64-linux and ia64-hpux.  This
>> patch changes the xfail so it only applies to ia64-*-*.  OK for trunk?
>
> Richard rejected a similar patch:
>
>        http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00054.html
>
> Perhaps Jan can suggest the correct approach?

We should verify that the call to val is inlined in all functions.
Maybe rename it to something larger and scan the optimized
dump so that name doesn't appear.

Richard.

>        Rainer
>
> --
> -----------------------------------------------------------------------------
> Rainer Orth, Center for Biotechnology, Bielefeld University
>
Jan Hubicka - May 25, 2011, 12:15 p.m.
Am Wed 25 May 2011 11:04:06 AM CEST schrieb Richard Guenther  
<richard.guenther@gmail.com>:

> On Wed, May 25, 2011 at 10:38 AM, Rainer Orth
> <ro@cebitec.uni-bielefeld.de> wrote:
>> Janis Johnson <janisjo@codesourcery.com> writes:
>>
>>> Archived test results for 4.7.0 for most processors with C++ results have:
>>>
>>> XPASS: g++.dg/tree-ssa/pr43411.C scan-tree-dump-not optimized   
>>> "OBJ_TYPE_REF"
>>>
>>> The only failures I could find were for ia64-linux and ia64-hpux.  This
>>> patch changes the xfail so it only applies to ia64-*-*.  OK for trunk?
>>
>> Richard rejected a similar patch:
>>
>>        http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00054.html
>>
>> Perhaps Jan can suggest the correct approach?
>
> We should verify that the call to val is inlined in all functions.
> Maybe rename it to something larger and scan the optimized
> dump so that name doesn't appear.
Indeed, this seems to be safest approach I can think of.
If function is supposed to be optimized out completely by early  
passes, we should just search release_ssa.  It is not the case here  
and dumping IPA info for inlining all instance would be bit tricky.

Honza
Mike Stump - May 25, 2011, 6:03 p.m.
On May 25, 2011, at 1:38 AM, Rainer Orth wrote:
> Janis Johnson <janisjo@codesourcery.com> writes:
> 
>> Archived test results for 4.7.0 for most processors with C++ results have:
>> 
>> XPASS: g++.dg/tree-ssa/pr43411.C scan-tree-dump-not optimized "OBJ_TYPE_REF"
>> 
>> The only failures I could find were for ia64-linux and ia64-hpux.  This
>> patch changes the xfail so it only applies to ia64-*-*.  OK for trunk?
> 
> Richard rejected a similar patch:

I see the two issues as orthogonal.  One issue it to have an accurate expectation for the actual testcase on actual targets.  The other is to modify the testcase to test something else.  While one can use the XPASS as a way of keeping track of the issue of improving the testcase, I'd rather approve the fix to fix the expected state and have people that want to track the other issue, instead of using XPASS to track that state, to use a PR instead.

I think it would be nice to go even farther, and that would be to set the expected state on all testcases on 6 platforms at the time of release, to expected, filing PRs for all failures (any unexpected result) so marked and to actually gate the release on no unexpected results.
Richard Guenther - May 26, 2011, 9:25 a.m.
On Wed, May 25, 2011 at 8:03 PM, Mike Stump <mikestump@comcast.net> wrote:
> On May 25, 2011, at 1:38 AM, Rainer Orth wrote:
>> Janis Johnson <janisjo@codesourcery.com> writes:
>>
>>> Archived test results for 4.7.0 for most processors with C++ results have:
>>>
>>> XPASS: g++.dg/tree-ssa/pr43411.C scan-tree-dump-not optimized "OBJ_TYPE_REF"
>>>
>>> The only failures I could find were for ia64-linux and ia64-hpux.  This
>>> patch changes the xfail so it only applies to ia64-*-*.  OK for trunk?
>>
>> Richard rejected a similar patch:
>
> I see the two issues as orthogonal.  One issue it to have an accurate expectation for the actual testcase on actual targets.  The other is to modify the testcase to test something else.  While one can use the XPASS as a way of keeping track of the issue of improving the testcase, I'd rather approve the fix to fix the expected state and have people that want to track the other issue, instead of using XPASS to track that state, to use a PR instead.
>
> I think it would be nice to go even farther, and that would be to set the expected state on all testcases on 6 platforms at the time of release, to expected, filing PRs for all failures (any unexpected result) so marked and to actually gate the release on no unexpected results.

The XPASS is suprious - that's the whole point of XPASSes.  It should
FAIL (well, XFAIL).  A patch making it PASS is bogus.

Richard.
Mike Stump - May 26, 2011, 3:16 p.m.
On May 26, 2011, at 2:25 AM, Richard Guenther wrote:
> The XPASS is suprious - that's the whole point of XPASSes.  It should
> FAIL (well, XFAIL).  A patch making it PASS is bogus.

There are deeper reasons for my position.  Take a look at:

  http://google1.osuosl.org:8011/waterfall

the idea is to use the expected state of the testcases to determine if the color should be green or not.  The best use of a system like this is when the usual state is green, and any time a red appears, it is turned back to green, in time measures in minutes or hours, not days or years.  Now, do you think there is any value add to having a testing system that displays testing results across many platforms on a regular basis like this?  If so, how do you propose to decide on wether the color should be green or red?
Richard Guenther - May 26, 2011, 3:55 p.m.
On Thu, May 26, 2011 at 5:16 PM, Mike Stump <mikestump@comcast.net> wrote:
> On May 26, 2011, at 2:25 AM, Richard Guenther wrote:
>> The XPASS is suprious - that's the whole point of XPASSes.  It should
>> FAIL (well, XFAIL).  A patch making it PASS is bogus.
>
> There are deeper reasons for my position.  Take a look at:
>
>  http://google1.osuosl.org:8011/waterfall
>
> the idea is to use the expected state of the testcases to determine if the color should be green or not.  The best use of a system like this is when the usual state is green, and any time a red appears, it is turned back to green, in time measures in minutes or hours, not days or years.  Now, do you think there is any value add to having a testing system that displays testing results across many platforms on a regular basis like this?  If so, how do you propose to decide on wether the color should be green or red?

It's always red on a transition.  Whether an XPASS or XFAIL is red on
its own needs human interaction (understanding of the testcase and
why it now XPASSes or XFAILs).  The red on the transition should
cause the human that did that transition to do that inspection.

Richard.
Mike Stump - May 26, 2011, 10:06 p.m.
On May 26, 2011, at 8:55 AM, Richard Guenther wrote:
> The red on the transition should cause the human that did that transition to do that inspection.

[ thinking about this some more ]  Agreed.  So, that means I should not just approve the XPASS -> PASS changes and that people that cause them should chime in instead.  Harder to always know just when they were put in and by who.  Thanks.

Patch

Index: g++.dg/tree-ssa/pr43411.C
===================================================================
--- g++.dg/tree-ssa/pr43411.C	(revision 174094)
+++ g++.dg/tree-ssa/pr43411.C	(working copy)
@@ -25,5 +25,5 @@ 
     sink1 = v(p);
 }
 
-// { dg-final { scan-tree-dump-not "OBJ_TYPE_REF" "optimized" { xfail *-*-* } } }
+// { dg-final { scan-tree-dump-not "OBJ_TYPE_REF" "optimized" { xfail ia64-*-* } } }
 // { dg-final { cleanup-tree-dump "optimized" } }