GCC testsuite maintenance (was: [PATCH] Fix OpenACC vector_length parsing in fortran)

[Thomas Schwinge <thomas at codesourcery dot com>]

Hi!

Including <gcc@gcc.gnu.org> in case others also have opinions on "GCC
testsuite maintenance".

On Fri, 15 Jul 2016 10:21:13 +0200, Jakub Jelinek <jakub@redhat.com> wrote:
> On Fri, Jul 15, 2016 at 09:44:25AM +0200, Thomas Schwinge wrote:
> > Does that me we (erroneously) accept any random junk after [...]
> 
> No.  The thing is, [...]

Thanks for the explanation!


> > On Thu, 14 Jul 2016 19:05:52 -0700, Cesar Philippidis <cesar@codesourcery.com> wrote:
> > > --- /dev/null
> > > +++ b/gcc/testsuite/gfortran.dg/goacc/vector_length.f90
> > > @@ -0,0 +1,11 @@
> > > +program t
> > > +  implicit none
> > > +  integer, parameter :: n = 100
> > > +  integer a(n), i
> > > +
> > > +  !$acc parallel loop num_gangs(100) num_workers(1) vector_length(32)
> > > +  do i = 1, n
> > > +     a(i) = i
> > > +  enddo
> > > +  !$acc end parallel loop
> > > +end program t
> > 
> > My preference is that such tests are added to existing test files, for
> > example where "!$acc parallel loop" is tested, instead of adding such
> > mini files.

One of the problem I have with this specific and similar other test cases
is, that when coming back to such a test case in a few weeks' time, it is
not obvious at all what this is testing, whereas if this were inside a
file that generally/already tests all kinds of "!$acc parallel loop"
variants, this would be obvious.

> No, we want to have as little churn as possible in existing tests, the
> general policy is to add new tests (not just for OpenACC/OpenMP, but for
> all functionality).

Hmm, that's something I had not been aware of, and I can't find this
covered in the documentation.  So, you're basically saying that files in
the testsuite are write-once, and should not be maintained aside from
fixing errors, adjusting due to optimization changes, or due to changed
diagnostics, and the like?  (Of course, I do agree that we shouldn't
"randomly" remove/modify test cases that test stuff that is still
relevant, but that doesn't apply here, obviously.)

In my opinion, the testsuite should be maintained, just like "regular"
code, and so related test cases should be consolidated, obsolete ones be
removed, and so on, every once in a while, or on demand.  So that the GCC
testsuite doesn't just always grow (in number of files), but also "stays
relevant".  Also, the wall-time overhead is much lower if, taking this
specific example, that one OpenACC directive test case is tested next to
others in an existing testsuite file, as opposed to requiring a separate
compiler invocation, being in a separate file.


Grüße
 Thomas