This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Library testsuite
- From: FX Coudert <fxcoudert at gmail dot com>
- To: Tobias Schlüter <tobias dot schlueter at physik dot uni-muenchen dot de>
- Cc: Fortran List <fortran at gcc dot gnu dot org>
- Date: Tue, 13 Feb 2007 02:17:56 +0100
- Subject: Re: Library testsuite
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=YV/7FobNUPXrTFQlho2waqB6zuTji+qJIWbP5UOIriYTeOHhb7wl/00n81SB+vCBP1OaOb48jYhacFNvZvVlyhXpSFHvTAp83VkWMc1r/n8wWIbX2f42mIVtKQUnp1s9RMFfVYCQgD8wWlbhJLlr6GUwjiyWSAHMVcaVq8+moiU=
- References: <45D10FB0.9080900@physik.uni-muenchen.de>
I'll just ask a silly question:
I divided the libgfortran testsuite into two subdirectories [...]
the tests in intrinsics cycle through the usual set of options.
If the tests in intrinsics are supposed to cover intrinsics for which
code is emitted directly by the front-end, why are we having them in
the library testsuite rather than the front-end testsuite?
Here's what I was thinking of:
1. put all I/O tests in an I/O directory in the libgfortran testsuite
2. create also a intrinsics directory, which is run with only one
optimization level, and
3. we clearly document the difference, and start moving stuff from
gfortran.dg to the libgfortran testsuite slowly, by taking care of
whether the test is actually testing front-end emitted code or rather
library calls
4. exercise same care when deciding where a new test will end up
Phase 3 can take some time, but it's OK because it will only take a
little more time than ideal, but we won't be laking testsuite coverage.
FX, who's writing a lot, but it's past 2am and I'm fed up with
writing my thesis :)