Library testsuite

[Tobias Schlüter]

Hi,

with all the talk about setting up complete testsuite coverage of 
intrinsics, I decided it is time to finally aim for a libgfortran 
testsuite.  I've setup a libgfortran testsuite in my tree, and it seems 
to work.  Before I start the effort of shuffling around thousands of 
testcases, I want to see if there is a general consensus that what I'm 
doing is right.

My intention was to speed up our current testsuite runtimes without 
sacrificing converage.  Tests of the library fall into two classes: 
those which exercise the optimizers, and those which don't.  The former 
are those which test library functionality that is implemented by inline 
code, the latter are those which are nothing but a series of calls into 
the library.  While for the former it is worthwhile to cycle through a 
set of different optimization options, for the latter it isn't.  But the 
distinction between these two is a moving target: e.g. (IIRC) currently 
the MVBITS intrinsic expands into a function call, but it is conceivable 
that someone will find it worthwhile write an inline implementation for it.

Therefore I decided to play it safe: I divided the libgfortran testsuite 
into two subdirectories: io/ and intrinsics/.  The tests in io/ are only 
run with -O2, whereas the tests in intrinsics cycle through the usual 
set of options.

Does anybody know a better solution?

- Tobi