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 00/16] Unit tests framework (v3)


On Mon, 2015-11-16 at 19:17 +0100, Bernd Schmidt wrote:
> So Jeff and I just had a chat, and we came up with some thoughts about 
> how to proceed. I think we both agree that it would be good to have a 
> special testing backend, along with frontends designed to be able to 
> read in gimple or rtl that can be operated on. That's more of a 
> long-term thing.

(nods)  FWIW, I'm interesting in trying to get the gimple FE into gcc 7.

> 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.

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.

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)

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.


Dave



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