This is the mail archive of the
mailing list for the GCC project.
Re: PATCH for Re: more evidence that failing to detect ICE's is a significant problem
>>>>> "Jason" == Jason Merrill <firstname.lastname@example.org> writes:
>>>>> Mark Mitchell <email@example.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?
>> 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
Will do. Thanks!
Mark Mitchell firstname.lastname@example.org
Mark Mitchell Consulting http://www.markmitchell.com