| Message ID | 4DDC05B3.2070007@codesourcery.com |
|---|---|
| State | New |
| Headers | show |
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.
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
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 >
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
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.
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.
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?
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.
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.
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" } }