On 11/16/2015 11:48 AM, David Malcolm wrote:
For some of the simpler infrastructure tests such as the ones in this
patch kit (bitmap, vec or wide-int functionality testing and such), we
had the idea of putting these into every ENABLE_CHECKING compiler, and
run them after building stage1, controlled by a -fself-test flag. It's
better to detect such basic failures early rather than complete a full
bootstrap and test cycle. It also keeps the tests alongside the rest of
the implementation, which I consider desirable for such relatively
simple data structures.
Would it be reasonable to run them at each stage? My hope is that they
will be fast.
But with what value? The point here is basic testing coverage of things
like low level data structures and such. The odds that we break
something in those that show up under unit testing during stage2/stage3,
but not during stage1 or during the compiler itself would be small I
would think.
If we're building the tests into the compiler itself, guarded by
#if ENABLE_CHECKING
then presumably it makes sense to put the tests directly into the
pertinent source files? (rather than in a "foo-tests.c" file). Possibly
even to interleave them, to be next to the code in question.
I'm of two minds. I really don't like the idea of lots of #ifs mucking
up the sources. So I'd tend to want them either at the end of the file
with a single #if CHECKING_P or as a separate foo-tests file. We may
want to get at static objects/functions from within a test (to either
set or query state), so that would tend to argue that within the
existing .c files.
Given that this patch kit has seen a fair amount of discussion, and
parts of it are already approved, and that it's designed to improve our
test coverage, is it reasonable to continue pursuing this within stage
3? (I hope so) Should I attempt a patch for the above? (once I've
fixed the AIX bootstrap issue, of course)
I'm leaning towards suggesting we get on a branch and look to merge it
into the next stage1. This isn't something that's going to have a user
impact.
Any thoughts on embedded gtest vs external gtest vs building our own?
If we're embedding, it may make most sense to build our own minimal
implementation, with a similar API (to avoid relying on the C++ stdlib,
which gtest does; that was the most awkward part of dealing with it,
iirc); this would be simpler, I suspect.
I'd lean towards external gtest. I realize it's another dependency, but
it's a testing only dependency, so it's not any worse in my mind than
dejagnu.
jeff
