| Message ID | yddwoq74hpm.fsf@CeBiTec.Uni-Bielefeld.DE |
|---|---|
| State | New |
| Headers | show |
| Series | [testsuite] Don't xfail gcc.dg/pr78973-2.c on non-ilp64 targets | expand |
On 10/24/18 7:06 AM, Rainer Orth wrote: > Between 20181022 (r265393) and 20181023 (r265430), gcc.dg/pr78973-2.c > began to XPASS on a large number of targets: > > +XPASS: gcc.dg/pr78973-2.c ilp32 (test for warnings, line 16) > > The following patch fixes this by removing the xfail on dg-warning. > Tested on i386-pc-solaris2.11, sparc-sun-solaris2.11, and > x86_64-pc-linux-gnu (both multilibs in every case). I'd usually just > install the patch as obvious, but am holding back since none of the > patches in that range obviously caused that. My first thought was that it was likely Richi's VRP fixes, but those are r265391, so just outside the range. His r265421 patch would be my next likely suspect :-) Jeff
Hi Jeff, > On 10/24/18 7:06 AM, Rainer Orth wrote: >> Between 20181022 (r265393) and 20181023 (r265430), gcc.dg/pr78973-2.c >> began to XPASS on a large number of targets: >> >> +XPASS: gcc.dg/pr78973-2.c ilp32 (test for warnings, line 16) >> >> The following patch fixes this by removing the xfail on dg-warning. >> Tested on i386-pc-solaris2.11, sparc-sun-solaris2.11, and >> x86_64-pc-linux-gnu (both multilibs in every case). I'd usually just >> install the patch as obvious, but am holding back since none of the >> patches in that range obviously caused that. > My first thought was that it was likely Richi's VRP fixes, but those are > r265391, so just outside the range. > > His r265421 patch would be my next likely suspect :-) you're right: I just reverted that patch in my tree, rebuilt cc1, and reran the test. Now it XFAILs again for 32 bit. Rainer
On 10/25/18 2:15 AM, Rainer Orth wrote: > Hi Jeff, > >> On 10/24/18 7:06 AM, Rainer Orth wrote: >>> Between 20181022 (r265393) and 20181023 (r265430), gcc.dg/pr78973-2.c >>> began to XPASS on a large number of targets: >>> >>> +XPASS: gcc.dg/pr78973-2.c ilp32 (test for warnings, line 16) >>> >>> The following patch fixes this by removing the xfail on dg-warning. >>> Tested on i386-pc-solaris2.11, sparc-sun-solaris2.11, and >>> x86_64-pc-linux-gnu (both multilibs in every case). I'd usually just >>> install the patch as obvious, but am holding back since none of the >>> patches in that range obviously caused that. >> My first thought was that it was likely Richi's VRP fixes, but those are >> r265391, so just outside the range. >> >> His r265421 patch would be my next likely suspect :-) > > you're right: I just reverted that patch in my tree, rebuilt cc1, and > reran the test. Now it XFAILs again for 32 bit. ACK. So while that change wasn't necessarily meant to fix this particular testcase, it does cause us to optimize earlier which in turn could (as a side effect) expose the ranges at an earlier point in the pipeline and allow us to generate proper warnings. So I'd say go with your change to drop the xfail. jeff
# HG changeset patch # Parent c704e85a30095c986599b2a7af488d213703bd44 Don't xfail gcc.dg/pr78973-2.c on non-ilp64 targets diff --git a/gcc/testsuite/gcc.dg/pr78973-2.c b/gcc/testsuite/gcc.dg/pr78973-2.c --- a/gcc/testsuite/gcc.dg/pr78973-2.c +++ b/gcc/testsuite/gcc.dg/pr78973-2.c @@ -14,7 +14,7 @@ void f (int n) { if (n <= 4) p = __builtin_malloc (n); - /* { dg-warning "argument 1 range \\\[\[0-9\]+, \[0-9\]+\\\] exceeds maximum object size 4" "ilp32" { xfail { ! lp64 } } .-1 } */ + /* { dg-warning "argument 1 range \\\[\[0-9\]+, \[0-9\]+\\\] exceeds maximum object size 4" "ilp32" { target *-*-* } .-1 } */ } void g (unsigned n)