This is the mail archive of the gcc-patches@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: [PATCH 01/15] Selftest framework (unittests v4)


On 11/19/2015 07:08 PM, David Malcolm wrote:
gcc_assert terminates the process and no further testing is done,
whereas the approach the kit tries to run as much of the testsuite as
possible, and then fail if any errors occurred.

Yeah, but let's say someone is working on bitmaps and one of the bitmap tests fail, it's somewhat unlikely that cfg will also fail (or if it does, it'll be a consequence of the earlier failure). You debug the issue, fix it, and run cc1 -fself-test again to see if that sorted it out.

As I said, it's a matter of taste and style and I won't claim that my way is necessarily the right one, but I do want to see if others feel the same.

The patch kit does use a lot of "magic" via macros and C++.

Taking registration/discovery/running in completely the other direction,
another approach could be a completely manual approach, with something
like this in toplev.c:

   bitmap_selftest ();
   et_forest_selftest ();
   /* etc */
   vec_selftest ();

This has the advantage of being explicit, and the disadvantage of
requiring a bit more typing.
(possibly passing in a "selftest *" param if we're doing the
try-to-run-everything approach, so we can count failures etc without
introducing globals)

Was that what you had in mind, or something else?

It's one option, but it doesn't seem like the best one either. I was thinking of something not dissimilar to your approach, but with fewer bells and whistles. My class registrator would look something like this:

static list<void (*)()> test_callbacks;

class registrator
{
public:
  registrator (void (*)() cb)
  {
    test_callbacks.push_front (cb);
  }
}

(or use a vec if you can do that at global constructor time)

and then you just walk the list and run the callbacks when you want to run tests. The one you have implements both the registration and a special case linked list, which just doesn't look right to me, and I think I'd also have avoided the runner class.


Bernd


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