Re: PATCH for Re: more evidence that failing to detect ICE's is a significant problem

[Mark Mitchell <mark at markmitchell dot com>]

>>>>> "Jason" == Jason Merrill <jason@cygnus.com> writes:

>>>>> Mark Mitchell <mark@markmitchell.com> writes:

    >> The issue was that we were not spotting a regression.

    >> This case should have been a FAIL, not an XFAIL, IMO.  Perhaps
    >> that's where we differ?

    Jason> Yep.

    >> Your code spotted the internal error, and called it a `FAIL'.
    >> But, then we saw the XFAIL, and called this an XFAIL.  That
    >> meant that even though we had what Joe Buck and I pereceived as
    >> a regression (a crash, versus a missed error), the testsuite
    >> didn't notify us.

    Jason> I see a crash and a missed error as two different failure
    Jason> modes for an error test, but I don't see the need to test
    Jason> for them separately.

I see your point of view.  What, however, do you think about a missed
*warning*?  There, I feel a crash would be a worse failure mode.
Wouldn't your version have marked such a thing as just an XFAIL?

I guess I'm thinking that not being able to XFAIL a crash isn't so
bad, and that missing crashes is very bad.  I use the testsuite as a
sanity check on my changes.  If, after I make a change, something
crashes, even if before some illegal/peculiar code failed to generate
a warning/error, I would probably not want to check in the change.

Perhaps we could cobble up something whereby an XFAIL line in the
header for the test could make a crash acceptable, but an XFAIL on an
ERROR/WARNING line would not allow a crash?  To me, this seems like
the right thing.  What do you think?

    >> Then that code should go.  One of the things that sometimes
    >> makes it difficult to work on GCC (and other programs, for that
    >> matter) is the presence of old code whose utility is unclear to
    >> the novice, like myself.

    Jason> Agreed; bitrot occurs in all systems.  Feel free to tear it
    Jason> out.

Will do.  Thanks!

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com