debugging for egcs

Mike Stump mrs@wrs.com
Mon Feb 23 15:57:00 GMT 1998


> From: Mike Simons <msimons@saic1.com>
> Date: Mon, 23 Feb 1998 05:07:43 -0500 (EST)
> Cc: egcs@cygnus.com

>   Speaking of testcases... do all of the short code bug examples
> reports posted to this list turn themselves into additional
> testsuite cases?

No, some just get dumped on the floor.  :-( Counter claims are
welcome.  They are in the mailing list archive, but I think that is
about it.  Unless you submit an AI testcase that knows how to add
itself to the testsuite, testcases will never add themselves to the
testsuite.  :-)

> If not, how should they be packaged so they *are* added to the
> regression suite?

Well, the word `regression' has a meaning, and not all of the little
bug examples are regressions.

It would be good to have an expected to be broken directory
(non-regression), and add all the various broken things to it.

They way to get a testcase into such a place, is to find out the right
place, and submit diffs to add it.

For C++, you can check out any (or all) of the C++ testcases, and get
a fairly good feel, fairly quickly.  `make check' isn't that hard to
type.

	make check-c++ 'RUNTESTFLAGS=-v -v old-deja.exp=eh6.C'

for example will run just a single C++ testcase.

A couple canonical example testcases:

    nit i;	// ERROR - we should get an error message

and:

    int i;	// gets bogus error - come on, compile it for me

As you can see, they are really easy to write, each one it just one
line, and hopefully is really easy to understand.  If people want to
add non-regression testcases into the testsuite, how about a new
directory, gcc/testsuite/g++.old-deja/g++.broken?  Just start
submitting diffs for new files (diff -N)...



More information about the Gcc mailing list