This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Big patch to contribute.html
On Mon, 7 Jun 2004, Giovanni Bajo wrote:
> Yes, I think that it is still worth to have what I wrote collected in a single
> page, as a coherent tutorial on how to write testcases for GCC. Even at the
> price of duplicating some information. Of course, some stuff can be linked from
> testcase.html (do you reckon this name is OK?) to sourcebuild.texi. Then, I can
> link testcase.html from both contribute.html and codingconventions.html.
I think the name's OK for a tutorial. The aim should be that the
information is present in the appropriate reference manuals (the DejaGnu
manual and the GCC manuals and codingconventions.html and contribute.html,
as applicable), but explained together in a tutorial with links to the
references.
> > The C headers that GCC includes, such as <limits.h> and <stddef.h>,
> > are fine for testcases to include.
>
> Uhm. For *bug* testcases, I am sure this is not needed, nor wanted, at least
> not enough to not have a general rule: bringing specific function declarations
> into scope makes testing faster, and "minimize" the testcase even further. For
> *feature* testcases, it might be different, I am not sure when exactly it might
> be needed. I can specify different conventions for these two cases though.
Testcases including <limits.h> and then using macros such as INT_MAX are
arguably more readable than ones using the predefine __INT_MAX__ directly.
Many do use the latter approach, but I don't think there's anything in
particular *against* the former.
> OK, though I was thinking of something along these lines:
> http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00289.html. Do you reckon those
> testcases are wrong? Otherwise I will have one of those as example here.
Not wrong, but it would be better for tests of optimizations to run across
multiple levels (and define the link_error function is !defined
__OPTIMIZE__). For a long time this wasn't so easy if the tests needed
special options (as the c-torture framework needed separate files to
specify those options), but c-torture now uses dg.exp and there is
gcc.dg/torture where diagnostics are meant to be matched as well. Many
gcc.dg tests that don't depend on the precise optimization level used (and
where that currently used is one of the standard torture ones) could have
their -O options removed (leaving the special ones) and be moved to
gcc.dg/torture.
--
Joseph S. Myers
jsm@polyomino.org.uk