This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Change rules for adding/changing test cases


> > > I definitely agree with the last point. What we do in the GNAT project is
> > > to assign a tracking number to every problem report. The test case is filed
> > > under this tracking number, and all revision history entries (which are 
> > > always detailed, and include how and why the problem was fixed) also include
> > > this same tracking number.
> > 
> > As I mentioned in another mail, not all gcc testcases have
> > corresponding bug reports to refer to, and it's not always efficient
> > to rely on a database halfway across the Internet to give you clues
> > about how to fix bugs a testcase catches.
> 
> But equally, the reason why a test fails on one target may be completely 
> different from the reason why it fails on another; so I see minimal uses 
> for such comments.  In the end, the only real way to debug a problem is to 
> run the compiler under a debugger and look at what is really going wrong.

That's right, "in the end," one resorts to a debugger. However, _in the begining_
one takes a quick look for clues. Any tools that can be brought to the table
during triage are useful; yes, it might be a dead-end; but that, in and of itself,
is useful information -- knowing what a bug _is not_ is often half the battle
of discovering what _it is_. I'm confident that truly mis-leading or useless
commentary would be rejected/modified as part of the normal patch submission
process. 


Jeff Knaggs

PS I don't intend to turn this thread into a discussion on 
debugging techniques. I won't be responding to further arguments
along this line.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]