Re: [PATCH 1/5] testsuite: attr-alloc_size-11.c (PR79356)
On 15/03/17 15:34, Rainer Orth wrote: Hi Jiong, Subject: [PATCH] testsuite, 79356 As stated in the PR (and elsewhere), this test now passes on aarch64, ia64, mips, powerpc, sparc, and s390x. This patch disables the xfails for those targets. gcc/testsuite/ PR testsuite/79356 * gcc.dg/attr-alloc_size-11.c: Don't xfail on aarch64, ia64, mips, powerpc, sparc, or s390x. It's passing on ARM as well. I will commit the following patch which add arm*-*-* to the "Don't xfail". gcc/testsuite/ PR testsuite/79356 * gcc.dg/attr-alloc_size-11.c: Don't xfail on arm. please keep the lists sorted alphabetically. Thanks, noticed that just during committing, the committed one has been corrected. https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/testsuite/gcc.dg/attr-alloc_size-11.c?r1=246167&r2=246166&pathrev=246167
Re: [PATCH 1/5] testsuite: attr-alloc_size-11.c (PR79356)
Hi Jiong, >> Subject: [PATCH] testsuite, 79356 >> >> As stated in the PR (and elsewhere), this test now passes on aarch64, >> ia64, mips, powerpc, sparc, and s390x. This patch disables the xfails >> for those targets. >> >> >> gcc/testsuite/ >> PR testsuite/79356 >> * gcc.dg/attr-alloc_size-11.c: Don't xfail on aarch64, ia64, mips, >> powerpc, sparc, or s390x. >> > It's passing on ARM as well. > > I will commit the following patch which add arm*-*-* to the "Don't xfail". > > gcc/testsuite/ > PR testsuite/79356 > * gcc.dg/attr-alloc_size-11.c: Don't xfail on arm. please keep the lists sorted alphabetically. Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH 1/5] testsuite: attr-alloc_size-11.c (PR79356)
On 10/03/17 15:26, Segher Boessenkool wrote:
On Fri, Mar 10, 2017 at 01:57:31PM +0100, Rainer Orth wrote:
I just noticed that nothing has happened at all in a month, so anything
is better than the tests XPASSing on a number of targets.
So the patch is ok for mainline with sparc*-*-* added to the target
lists and a reference to PR testsuite/79356 in the comment.
I'd still be very grateful if Martin could have a look what's really
going on here, though.
Same here.
Committed as:
Subject: [PATCH] testsuite, 79356
As stated in the PR (and elsewhere), this test now passes on aarch64,
ia64, mips, powerpc, sparc, and s390x. This patch disables the xfails
for those targets.
gcc/testsuite/
PR testsuite/79356
* gcc.dg/attr-alloc_size-11.c: Don't xfail on aarch64, ia64, mips,
powerpc, sparc, or s390x.
It's passing on ARM as well.
I will commit the following patch which add arm*-*-* to the "Don't xfail".
gcc/testsuite/
PR testsuite/79356
* gcc.dg/attr-alloc_size-11.c: Don't xfail on arm.
diff --git a/gcc/testsuite/gcc.dg/attr-alloc_size-11.c b/gcc/testsuite/gcc.dg/attr-alloc_size-11.c
index ccf2c2196c065b3387a91cc764dad3fcc1b4e3ee..3c1867bfb4e1cb762308dc6ac03afc7dc01cc075 100644
--- a/gcc/testsuite/gcc.dg/attr-alloc_size-11.c
+++ b/gcc/testsuite/gcc.dg/attr-alloc_size-11.c
@@ -47,8 +47,8 @@ typedef __SIZE_TYPE__size_t;
/* The following tests fail because of missing range information. The xfail
exclusions are PR79356. */
-TEST (signed char, SCHAR_MIN + 2, ALLOC_MAX); /* { dg-warning "argument 1 range \\\[13, \[0-9\]+\\\] exceeds maximum object size 12" "missing range info for signed char" { xfail { ! { aarch64*-*-* ia64-*-* mips*-*-* powerpc*-*-* sparc*-*-* s390x-*-* } } } } */
-TEST (short, SHRT_MIN + 2, ALLOC_MAX); /* { dg-warning "argument 1 range \\\[13, \[0-9\]+\\\] exceeds maximum object size 12" "missing range info for short" { xfail { ! { aarch64*-*-* ia64-*-* mips*-*-* powerpc*-*-* sparc*-*-* s390x-*-* } } } } */
+TEST (signed char, SCHAR_MIN + 2, ALLOC_MAX); /* { dg-warning "argument 1 range \\\[13, \[0-9\]+\\\] exceeds maximum object size 12" "missing range info for signed char" { xfail { ! { arm*-*-* aarch64*-*-* ia64-*-* mips*-*-* powerpc*-*-* sparc*-*-* s390x-*-* } } } } */
+TEST (short, SHRT_MIN + 2, ALLOC_MAX); /* { dg-warning "argument 1 range \\\[13, \[0-9\]+\\\] exceeds maximum object size 12" "missing range info for short" { xfail { ! { arm*-*-* aarch64*-*-* ia64-*-* mips*-*-* powerpc*-*-* sparc*-*-* s390x-*-* } } } } */
TEST (int, INT_MIN + 2, ALLOC_MAX);/* { dg-warning "argument 1 range \\\[13, \[0-9\]+\\\] exceeds maximum object size 12" } */
TEST (int, -3, ALLOC_MAX); /* { dg-warning "argument 1 range \\\[13, \[0-9\]+\\\] exceeds maximum object size 12" } */
TEST (int, -2, ALLOC_MAX); /* { dg-warning "argument 1 range \\\[13, \[0-9\]+\\\] exceeds maximum object size 12" } */
Re: [PATCH 1/5] testsuite: attr-alloc_size-11.c (PR79356)
On 03/12/2017 07:32 PM, Martin Sebor wrote:
On 03/10/2017 10:51 PM, Jeff Law wrote:
On 03/10/2017 09:20 AM, Martin Sebor wrote:
On 03/10/2017 05:57 AM, Rainer Orth wrote:
Hi Segher,
On Fri, Feb 10, 2017 at 11:56:39AM +0100, Rainer Orth wrote:
Segher Boessenkool writes:
As stated in the PR, this test now passes on aarch64, ia64, powerpc,
and s390x. This patch disables the xfails for those targets.
As I'd mentioned in PR tree-optimization/78775, the test XPASSes on
SPARC, too.
Tested on powerpc64-linux {-m32,-m64}. Is this okay for trunk?
[...]
2017-02-09 Segher Boessenkool
gcc/testsuite/
PR testsuite/79356
* gcc.dg/attr-alloc_size-11.c: Don't xfail on aarch64, ia64,
powerpc,
or s390x.
TBH, I'd strongly prefer to have a proper analysis instead of just
un-xfail-ing the test on an ever growing apparently random list of
targets.
Yeah, I agree. I thought it was just another test that stopped
failing,
but it seems to fail in two ways now, making the testcase succeed?
Lovely. Please consider this patch withdrawn.
I just noticed that nothing has happened at all in a month, so anything
is better than the tests XPASSing on a number of targets.
So the patch is ok for mainline with sparc*-*-* added to the target
lists and a reference to PR testsuite/79356 in the comment.
I'd still be very grateful if Martin could have a look what's really
going on here, though.
Sorry, I haven't had a chance to look more deeply into why these
assertions pass on some targets and fail on others. There is at
least one bug that tracks a VRP problem that manifests only on
some targets and not others (79054). I don't know if this is
a symptom of the same bug or something different. I'll see if
I can find some time to isolate it.
It could well be a BRANCH_COST effect. BRANCH_COST is probably the most
annoying target property that bleeds into the tree/gimple world. From
looking at the gimple in the BZ that could well be the case.
See logical_op_short_circuit for how this is often dealt with in the
testsuite.
Thanks for the hint. I extracted the test case from
attr-alloc_size-11.c and reproduced the discrepancy on powerpc64le
and x86_64. It looks to me like two bugs(?) conspire to trigger
it. I opened pr80006 with the details and I'm working on a patch.
Here's some more detail. First, on x86_64 (but not on powerpc64le
and I suspect the other targets where this assertion passes), GCC
very early on introduces a spurious conversion from signed char to
int. For instance, given:
void* f (signed char x)
{
extern void* ff (signed char) __attribute__ ((alloc_size (1)));
if (-3 <= x && x <= 7)
x = -4;
return ff (x);
}
the tree-original dump on x86_64 is as follows (note the (int)x
cast):
;; Function f (null)
;; enabled by -tree-original
{
extern void * ff (signed char);
if ((unsigned char) x + 3 <= 10)
{
x = -4;
}
return ff ((int) x); <<< spurious cast
}
while the following the same dump on powerpc64le (no cast):
;; Function f (null)
;; enabled by -tree-original
{
extern void * ff (signed char);
if ((unsigned char) x + 3 <= 10)
{
x = -4;
}
return ff (x); <<< no cast
}
Those differences could well be related to promotions implied by the ABI
in use on each target. Those certainly happen too, they're just not as
common a problem as the logical_op_short_circuit stuff.
The cast makes its way to VRP where it causes the range on x
to be lost in the conversion to the temporary it introduces:
Found new range for x_4: ~[-3, 7]
marking stmt to be not simulated again
Visiting statement:
_9 = (int) x_4;
Meeting
[-128, -4]
and
[8, 127]
to
[-128, 127]
Found new range for _9: [-128, 127] <<< anti-range lost
Seems like a problem. Given that we're converting to a wider type, we
ought to be able to do better and not lose the anti range.
...
Visiting PHI node: prephitmp_10 = PHI <_9(3), -4(2)>
...
Meeting
[-128, 127]
and
[-4, -4]
to
[-128, 127]
Intersecting
[-128, 127]
and
[-128, 127]
to
[-128, 127]
Found new range for prephitmp_10: [-128, 127]
...
Visiting statement:
_8 = ff (prephitmp_10);
ISTM that ~[-3,7] U -4 should result in ~[-3,7], right? The
union/intersection of ANTI ranges looked like it could use some
improvement when I was in there last month, so I wouldn't be surprised
if it needs some improvement.
Debugging tree-vrp.c suggests that this is a deficiency in
the extract_range_from_unary_expr function the computes the
range of the result of the NOP_EXPR (the cast) of an SSA_NAME
with an anti-range ~[A, B] as a union of [TYPE_MIN, A - 1] and
[B + 1, TYPE_MAX], which for ~[-3, 7] and the signed char x in
the test case results in [SCHAR_MIN, -4] U [8, SCHAR_MAX], or
[SCHAR_MIN, SCHAR_MAX]. There's a comment in the function
that reads:
/* Now canonicalize anti-ranges to ranges when
Re: [PATCH 1/5] testsuite: attr-alloc_size-11.c (PR79356)
On 03/10/2017 10:51 PM, Jeff Law wrote:
On 03/10/2017 09:20 AM, Martin Sebor wrote:
On 03/10/2017 05:57 AM, Rainer Orth wrote:
Hi Segher,
On Fri, Feb 10, 2017 at 11:56:39AM +0100, Rainer Orth wrote:
Segher Boessenkool writes:
As stated in the PR, this test now passes on aarch64, ia64, powerpc,
and s390x. This patch disables the xfails for those targets.
As I'd mentioned in PR tree-optimization/78775, the test XPASSes on
SPARC, too.
Tested on powerpc64-linux {-m32,-m64}. Is this okay for trunk?
[...]
2017-02-09 Segher Boessenkool
gcc/testsuite/
PR testsuite/79356
* gcc.dg/attr-alloc_size-11.c: Don't xfail on aarch64, ia64,
powerpc,
or s390x.
TBH, I'd strongly prefer to have a proper analysis instead of just
un-xfail-ing the test on an ever growing apparently random list of
targets.
Yeah, I agree. I thought it was just another test that stopped
failing,
but it seems to fail in two ways now, making the testcase succeed?
Lovely. Please consider this patch withdrawn.
I just noticed that nothing has happened at all in a month, so anything
is better than the tests XPASSing on a number of targets.
So the patch is ok for mainline with sparc*-*-* added to the target
lists and a reference to PR testsuite/79356 in the comment.
I'd still be very grateful if Martin could have a look what's really
going on here, though.
Sorry, I haven't had a chance to look more deeply into why these
assertions pass on some targets and fail on others. There is at
least one bug that tracks a VRP problem that manifests only on
some targets and not others (79054). I don't know if this is
a symptom of the same bug or something different. I'll see if
I can find some time to isolate it.
It could well be a BRANCH_COST effect. BRANCH_COST is probably the most
annoying target property that bleeds into the tree/gimple world. From
looking at the gimple in the BZ that could well be the case.
See logical_op_short_circuit for how this is often dealt with in the
testsuite.
Thanks for the hint. I extracted the test case from
attr-alloc_size-11.c and reproduced the discrepancy on powerpc64le
and x86_64. It looks to me like two bugs(?) conspire to trigger
it. I opened pr80006 with the details and I'm working on a patch.
Here's some more detail. First, on x86_64 (but not on powerpc64le
and I suspect the other targets where this assertion passes), GCC
very early on introduces a spurious conversion from signed char to
int. For instance, given:
void* f (signed char x)
{
extern void* ff (signed char) __attribute__ ((alloc_size (1)));
if (-3 <= x && x <= 7)
x = -4;
return ff (x);
}
the tree-original dump on x86_64 is as follows (note the (int)x
cast):
;; Function f (null)
;; enabled by -tree-original
{
extern void * ff (signed char);
if ((unsigned char) x + 3 <= 10)
{
x = -4;
}
return ff ((int) x); <<< spurious cast
}
while the following the same dump on powerpc64le (no cast):
;; Function f (null)
;; enabled by -tree-original
{
extern void * ff (signed char);
if ((unsigned char) x + 3 <= 10)
{
x = -4;
}
return ff (x); <<< no cast
}
The cast makes its way to VRP where it causes the range on x
to be lost in the conversion to the temporary it introduces:
Found new range for x_4: ~[-3, 7]
marking stmt to be not simulated again
Visiting statement:
_9 = (int) x_4;
Meeting
[-128, -4]
and
[8, 127]
to
[-128, 127]
Found new range for _9: [-128, 127] <<< anti-range lost
...
Visiting PHI node: prephitmp_10 = PHI <_9(3), -4(2)>
...
Meeting
[-128, 127]
and
[-4, -4]
to
[-128, 127]
Intersecting
[-128, 127]
and
[-128, 127]
to
[-128, 127]
Found new range for prephitmp_10: [-128, 127]
...
Visiting statement:
_8 = ff (prephitmp_10);
Debugging tree-vrp.c suggests that this is a deficiency in
the extract_range_from_unary_expr function the computes the
range of the result of the NOP_EXPR (the cast) of an SSA_NAME
with an anti-range ~[A, B] as a union of [TYPE_MIN, A - 1] and
[B + 1, TYPE_MAX], which for ~[-3, 7] and the signed char x in
the test case results in [SCHAR_MIN, -4] U [8, SCHAR_MAX], or
[SCHAR_MIN, SCHAR_MAX]. There's a comment in the function
that reads:
/* Now canonicalize anti-ranges to ranges when they are not
symbolic and express op ~[] as (op []') U (op []''). */
indicating this is deliberate but I have no idea why or if
it's important.
After adding code to handle this case none of the VRP tests
broke so maybe it's just an oversight. But even with this
case handled and the anti-range propagated to the result of
the cast, there's still a problem. The vrp_visit_phi_node
function that updates the range of the result of a PHI node
merges the existing range of the LHS with the range of the
PHI. This again results in the anti-range being lost and
replaced with that of the type of the RHS (signed char
Re: [PATCH 1/5] testsuite: attr-alloc_size-11.c (PR79356)
On 03/10/2017 09:20 AM, Martin Sebor wrote:
On 03/10/2017 05:57 AM, Rainer Orth wrote:
Hi Segher,
On Fri, Feb 10, 2017 at 11:56:39AM +0100, Rainer Orth wrote:
Segher Boessenkool writes:
As stated in the PR, this test now passes on aarch64, ia64, powerpc,
and s390x. This patch disables the xfails for those targets.
As I'd mentioned in PR tree-optimization/78775, the test XPASSes on
SPARC, too.
Tested on powerpc64-linux {-m32,-m64}. Is this okay for trunk?
[...]
2017-02-09 Segher Boessenkool
gcc/testsuite/
PR testsuite/79356
* gcc.dg/attr-alloc_size-11.c: Don't xfail on aarch64, ia64,
powerpc,
or s390x.
TBH, I'd strongly prefer to have a proper analysis instead of just
un-xfail-ing the test on an ever growing apparently random list of
targets.
Yeah, I agree. I thought it was just another test that stopped failing,
but it seems to fail in two ways now, making the testcase succeed?
Lovely. Please consider this patch withdrawn.
I just noticed that nothing has happened at all in a month, so anything
is better than the tests XPASSing on a number of targets.
So the patch is ok for mainline with sparc*-*-* added to the target
lists and a reference to PR testsuite/79356 in the comment.
I'd still be very grateful if Martin could have a look what's really
going on here, though.
Sorry, I haven't had a chance to look more deeply into why these
assertions pass on some targets and fail on others. There is at
least one bug that tracks a VRP problem that manifests only on
some targets and not others (79054). I don't know if this is
a symptom of the same bug or something different. I'll see if
I can find some time to isolate it.
It could well be a BRANCH_COST effect. BRANCH_COST is probably the most
annoying target property that bleeds into the tree/gimple world. From
looking at the gimple in the BZ that could well be the case.
See logical_op_short_circuit for how this is often dealt with in the
testsuite.
jeff
Re: [PATCH 1/5] testsuite: attr-alloc_size-11.c (PR79356)
On 03/10/2017 05:57 AM, Rainer Orth wrote:
Hi Segher,
On Fri, Feb 10, 2017 at 11:56:39AM +0100, Rainer Orth wrote:
Segher Boessenkool writes:
As stated in the PR, this test now passes on aarch64, ia64, powerpc,
and s390x. This patch disables the xfails for those targets.
As I'd mentioned in PR tree-optimization/78775, the test XPASSes on
SPARC, too.
Tested on powerpc64-linux {-m32,-m64}. Is this okay for trunk?
[...]
2017-02-09 Segher Boessenkool
gcc/testsuite/
PR testsuite/79356
* gcc.dg/attr-alloc_size-11.c: Don't xfail on aarch64, ia64, powerpc,
or s390x.
TBH, I'd strongly prefer to have a proper analysis instead of just
un-xfail-ing the test on an ever growing apparently random list of
targets.
Yeah, I agree. I thought it was just another test that stopped failing,
but it seems to fail in two ways now, making the testcase succeed?
Lovely. Please consider this patch withdrawn.
I just noticed that nothing has happened at all in a month, so anything
is better than the tests XPASSing on a number of targets.
So the patch is ok for mainline with sparc*-*-* added to the target
lists and a reference to PR testsuite/79356 in the comment.
I'd still be very grateful if Martin could have a look what's really
going on here, though.
Sorry, I haven't had a chance to look more deeply into why these
assertions pass on some targets and fail on others. There is at
least one bug that tracks a VRP problem that manifests only on
some targets and not others (79054). I don't know if this is
a symptom of the same bug or something different. I'll see if
I can find some time to isolate it.
Martin
Re: [PATCH 1/5] testsuite: attr-alloc_size-11.c (PR79356)
On Fri, Mar 10, 2017 at 01:57:31PM +0100, Rainer Orth wrote:
> I just noticed that nothing has happened at all in a month, so anything
> is better than the tests XPASSing on a number of targets.
>
> So the patch is ok for mainline with sparc*-*-* added to the target
> lists and a reference to PR testsuite/79356 in the comment.
>
> I'd still be very grateful if Martin could have a look what's really
> going on here, though.
Same here.
Committed as:
Subject: [PATCH] testsuite, 79356
As stated in the PR (and elsewhere), this test now passes on aarch64,
ia64, mips, powerpc, sparc, and s390x. This patch disables the xfails
for those targets.
gcc/testsuite/
PR testsuite/79356
* gcc.dg/attr-alloc_size-11.c: Don't xfail on aarch64, ia64, mips,
powerpc, sparc, or s390x.
---
gcc/testsuite/gcc.dg/attr-alloc_size-11.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/attr-alloc_size-11.c
b/gcc/testsuite/gcc.dg/attr-alloc_size-11.c
index fac8b18..fe0cb5c 100644
--- a/gcc/testsuite/gcc.dg/attr-alloc_size-11.c
+++ b/gcc/testsuite/gcc.dg/attr-alloc_size-11.c
@@ -45,10 +45,10 @@ typedef __SIZE_TYPE__size_t;
return CAT (alloc_anti_range_, __LINE__)(n); \
} typedef void dummy /* Require a semicolon. */
-/* The following tests fail because of missing range information. */
-TEST (signed char, SCHAR_MIN + 2, ALLOC_MAX); /* { dg-warning "argument 1
range \\\[13, \[0-9\]+\\\] exceeds maximum object size 12" "missing range info
for signed char" { xfail *-*-* } } */
-TEST (short, SHRT_MIN + 2, ALLOC_MAX); /* { dg-warning "argument 1 range
\\\[13, \[0-9\]+\\\] exceeds maximum object size 12" "missing range info for
short" { xfail *-*-* } } */
-
+/* The following tests fail because of missing range information. The xfail
+ exclusions are PR79356. */
+TEST (signed char, SCHAR_MIN + 2, ALLOC_MAX); /* { dg-warning "argument 1
range \\\[13, \[0-9\]+\\\] exceeds maximum object size 12" "missing range info
for signed char" { xfail { ! { aarch64*-*-* ia64-*-* mips*-*-* powerpc*-*-*
sparc*-*-* s390x-*-* } } } } */
+TEST (short, SHRT_MIN + 2, ALLOC_MAX); /* { dg-warning "argument 1 range
\\\[13, \[0-9\]+\\\] exceeds maximum object size 12" "missing range info for
short" { xfail { ! { aarch64*-*-* ia64-*-* mips*-*-* powerpc*-*-* sparc*-*-*
s390x-*-* } } } } */
TEST (int, INT_MIN + 2, ALLOC_MAX);/* { dg-warning "argument 1 range
\\\[13, \[0-9\]+\\\] exceeds maximum object size 12" } */
TEST (int, -3, ALLOC_MAX); /* { dg-warning "argument 1 range
\\\[13, \[0-9\]+\\\] exceeds maximum object size 12" } */
TEST (int, -2, ALLOC_MAX); /* { dg-warning "argument 1 range
\\\[13, \[0-9\]+\\\] exceeds maximum object size 12" } */
--
1.9.3
Re: [PATCH 1/5] testsuite: attr-alloc_size-11.c (PR79356)
On Fri, Mar 10, 2017 at 03:31:39PM +0100, Rainer Orth wrote: > Hi Toma, > > >> I just noticed that nothing has happened at all in a month, so anything > >> is better than the tests XPASSing on a number of targets. > >> > >> So the patch is ok for mainline with sparc*-*-* added to the target > >> lists and a reference to PR testsuite/79356 in the comment. > >> > >> I'd still be very grateful if Martin could have a look what's really > >> going on here, though. > > > This test has also been XPASS-ing for mips-mti-elf and mips-mti-linux-gnu, > > so I think you could also add mips*-*-* to the xfail targets. > > no argument from me. This just underlines that someone needs to > investigate what's really going on here. > > Consider such a patch pre-approved. gcc-testresults shows it passing on some other mips targets as well. I'll include it. Segher
Re: [PATCH 1/5] testsuite: attr-alloc_size-11.c (PR79356)
Hi Toma, >> I just noticed that nothing has happened at all in a month, so anything >> is better than the tests XPASSing on a number of targets. >> >> So the patch is ok for mainline with sparc*-*-* added to the target >> lists and a reference to PR testsuite/79356 in the comment. >> >> I'd still be very grateful if Martin could have a look what's really >> going on here, though. > This test has also been XPASS-ing for mips-mti-elf and mips-mti-linux-gnu, > so I think you could also add mips*-*-* to the xfail targets. no argument from me. This just underlines that someone needs to investigate what's really going on here. Consider such a patch pre-approved. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
RE: [PATCH 1/5] testsuite: attr-alloc_size-11.c (PR79356)
> > I just noticed that nothing has happened at all in a month, so anything > is better than the tests XPASSing on a number of targets. > > So the patch is ok for mainline with sparc*-*-* added to the target > lists and a reference to PR testsuite/79356 in the comment. > > I'd still be very grateful if Martin could have a look what's really > going on here, though. > > Thanks. > Rainer > Hi, This test has also been XPASS-ing for mips-mti-elf and mips-mti-linux-gnu, so I think you could also add mips*-*-* to the xfail targets. Regards, Toma
Re: [PATCH 1/5] testsuite: attr-alloc_size-11.c (PR79356)
Hi Segher,
> On Fri, Feb 10, 2017 at 11:56:39AM +0100, Rainer Orth wrote:
>> Segher Boessenkool writes:
>>
>> > As stated in the PR, this test now passes on aarch64, ia64, powerpc,
>> > and s390x. This patch disables the xfails for those targets.
>>
>> As I'd mentioned in PR tree-optimization/78775, the test XPASSes on
>> SPARC, too.
>>
>> > Tested on powerpc64-linux {-m32,-m64}. Is this okay for trunk?
>> [...]
>> > 2017-02-09 Segher Boessenkool
>> >
>> > gcc/testsuite/
>> >PR testsuite/79356
>> >* gcc.dg/attr-alloc_size-11.c: Don't xfail on aarch64, ia64, powerpc,
>> >or s390x.
>>
>> TBH, I'd strongly prefer to have a proper analysis instead of just
>> un-xfail-ing the test on an ever growing apparently random list of
>> targets.
>
> Yeah, I agree. I thought it was just another test that stopped failing,
> but it seems to fail in two ways now, making the testcase succeed?
> Lovely. Please consider this patch withdrawn.
I just noticed that nothing has happened at all in a month, so anything
is better than the tests XPASSing on a number of targets.
So the patch is ok for mainline with sparc*-*-* added to the target
lists and a reference to PR testsuite/79356 in the comment.
I'd still be very grateful if Martin could have a look what's really
going on here, though.
Thanks.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH 1/5] testsuite: attr-alloc_size-11.c (PR79356)
On Fri, Feb 10, 2017 at 11:56:39AM +0100, Rainer Orth wrote:
> Segher Boessenkool writes:
>
> > As stated in the PR, this test now passes on aarch64, ia64, powerpc,
> > and s390x. This patch disables the xfails for those targets.
>
> As I'd mentioned in PR tree-optimization/78775, the test XPASSes on
> SPARC, too.
>
> > Tested on powerpc64-linux {-m32,-m64}. Is this okay for trunk?
> [...]
> > 2017-02-09 Segher Boessenkool
> >
> > gcc/testsuite/
> > PR testsuite/79356
> > * gcc.dg/attr-alloc_size-11.c: Don't xfail on aarch64, ia64, powerpc,
> > or s390x.
>
> TBH, I'd strongly prefer to have a proper analysis instead of just
> un-xfail-ing the test on an ever growing apparently random list of
> targets.
Yeah, I agree. I thought it was just another test that stopped failing,
but it seems to fail in two ways now, making the testcase succeed?
Lovely. Please consider this patch withdrawn.
Segher
Re: [PATCH 1/5] testsuite: attr-alloc_size-11.c (PR79356)
Segher Boessenkool writes:
> As stated in the PR, this test now passes on aarch64, ia64, powerpc,
> and s390x. This patch disables the xfails for those targets.
As I'd mentioned in PR tree-optimization/78775, the test XPASSes on
SPARC, too.
> Tested on powerpc64-linux {-m32,-m64}. Is this okay for trunk?
[...]
> 2017-02-09 Segher Boessenkool
>
> gcc/testsuite/
> PR testsuite/79356
> * gcc.dg/attr-alloc_size-11.c: Don't xfail on aarch64, ia64, powerpc,
> or s390x.
TBH, I'd strongly prefer to have a proper analysis instead of just
un-xfail-ing the test on an ever growing apparently random list of
targets.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
