g++.pt/lss-*.C

[Jeffrey A Law]

  In message < 37C63874.DC6731E8@pobox.com >you write:
  > Trying to organize test cases by "feature" could be difficult, and
  > possibly even counterproductive.  Failures in software of the complexity
  > of GCC are often interactions between multiple features or multiple
  > internal layers.  The primary value of test cases, I think, is to shine
  > light into such overlooked corners.
In some cases, yes I agree.  In other cases I do not.

For example, we have a large number of tests which test for a variety of
issues with nested functions.  Then another batch for label values, then
another (large) batch for passing structures to varargs/stdarg routines.

Those would be prime candidates for trying to gather together.  As someone
who is often involved in bringing up new ports having tests in some rough
categories really helps organize the "what test do I fix now" problem.

  > Most of the test cases I submitted, for example, are interactions
  > between templates and other features of C++, either one of which works
  > fine in isolation.  I also suspect some inter-layer confusion within GCC
  > (because templates add complexity to the already delicate feedback
  > between parsing and semantics in C++).  The bug Martin squashed based on
  > my reports was of the latter form (member templates were not assigned
  > proper context info and so where not recognized as syntactically valid
  > template template parameters).

Maybe the difference of opinion comes from looking at different tests?  I
spend the vast majority of my time looking at C tests, not C++ tests
(even though there is a large directory of C++ tests with my name attached
to them).

In the C++ world, being able to separate out stuff like basic ctor/dtor 
support,
EH support, etc would be a win too since those are usually the two areas were
new ports always fall down initially.


jeff