On Wed, 14 Mar 2007, Joe Buck wrote:
If we allow XFAILing tests that ICE, it should be an extremely rare thing.
I worry that once the precedent is set, the number of XFAIL ICEs will
go up with time, making it more likely that users will experience
compiler crashes.
What's so bad about an ICE
On 3/15/07, Janis Johnson [EMAIL PROTECTED] wrote:
On Thu, Mar 15, 2007 at 04:58:51AM -0400, Hans-Peter Nilsson wrote:
On Wed, 14 Mar 2007, Joe Buck wrote:
If we allow XFAILing tests that ICE, it should be an extremely rare thing.
I worry that once the precedent is set, the number of XFAIL
On Mar 14, 2007, at 11:12 PM, Mark Mitchell wrote:
Zero FAILs may not be achievable on all targets, but if I had a
magic XFAIL wand, that would put the right XFAIL goo into all tests
before every release so that all users who built the toolchain
correctly always got zero FAILs, I would do
On Wed, Mar 14, 2007 at 03:47:57AM +, Joseph S. Myers wrote:
On Tue, 13 Mar 2007, Andrew Pinski wrote:
Anyways the best way to fix this is just to fix the bug. Someone
We should have 0 unexpected FAILs in 4.2.0 on common platforms (in
particular the primary release criteria ones for
On Wed, Mar 14, 2007 at 03:47:57AM +, Joseph S. Myers wrote:
It's not punishing the testcase; it's recognising that we have a bug
tracking system to track regressions and having expected unexpected
FAILs is helpful neither to users wishing to know if their compiler built
as
Joe Buck [EMAIL PROTECTED] writes:
On Wed, Mar 14, 2007 at 03:47:57AM +, Joseph S. Myers wrote:
It's not punishing the testcase; it's recognising that we have a bug
tracking system to track regressions and having expected unexpected
FAILs is helpful neither to users wishing to
Janis Johnson wrote:
It's not punishing the testcase; it's recognising that we have a bug
tracking system to track regressions and having expected unexpected
FAILs is helpful neither to users wishing to know if their compiler built
as expected nor to developers glancing over test results
Hi Janis,
While PR 28834 stays open, I'm thinking about XFAILing
gcc.c-torture/execute/mayalias-2.c when it is run with -O3 -g.
However, I am not having any luck with writing mayalias-2.x. I am
wondering if you could help me with XFAIL.
When I try mayalias-2.x like so:
set
On 3/13/07, Kazu Hirata [EMAIL PROTECTED] wrote:
Hi Janis,
While PR 28834 stays open, I'm thinking about XFAILing
gcc.c-torture/execute/mayalias-2.c when it is run with -O3 -g.
However, I am not having any luck with writing mayalias-2.x. I am
wondering if you could help me with XFAIL.
There
On Tue, Mar 13, 2007 at 12:28:22PM -0700, Kazu Hirata wrote:
Hi Janis,
While PR 28834 stays open, I'm thinking about XFAILing
gcc.c-torture/execute/mayalias-2.c when it is run with -O3 -g.
However, I am not having any luck with writing mayalias-2.x. I am
wondering if you could help me with
On Tue, 13 Mar 2007, Andrew Pinski wrote:
On 3/13/07, Kazu Hirata [EMAIL PROTECTED] wrote:
Hi Janis,
While PR 28834 stays open, I'm thinking about XFAILing
gcc.c-torture/execute/mayalias-2.c when it is run with -O3 -g.
However, I am not having any luck with writing mayalias-2.x. I am
On 3/13/07, Joseph S. Myers [EMAIL PROTECTED] wrote:
On Tue, 13 Mar 2007, Andrew Pinski wrote:
It's true that in development we may not want to XFAIL them - but it's
also true that this FAIL is on 4.2 branch and 4.2.0 is likely to be
released with it. And users installing GCC on common
On Tue, 13 Mar 2007, Andrew Pinski wrote:
Anyways the best way to fix this is just to fix the bug. Someone
We should have 0 unexpected FAILs in 4.2.0 on common platforms (in
particular the primary release criteria ones for the testsuites of the
languages in the release criteria). How this is
13 matches
Mail list logo
