New testcase for c-parse.in

Neil Booth neil@daikokuya.demon.co.uk
Sat Feb 16 10:45:00 GMT 2002


Joseph S. Myers wrote:-

> Name tests conceptually, not after paragraph numbers.

Yes, that's probably a better plan.  However, coming up with reasonable
names can be hard.

> However, a gcc.dg/std subdirectory [...] would be a good idea.

How about a subdirectory per chapter, e.g. "gcc.dg/std-decl"?  The idea
being that all tests relating to the declaration chapter from all
standards go in there.  Those that do not apply to all 3 revisions can
be prefixed with e.g. "C99", but most tests should not require a prefix.
 
> A single test per standard requirement isn't enough.  In general there are 
> many tests for each requirement, covering several variations on the same 
> theme, and corner cases, and cases that the code handles differently.

Of course, that's why I mentioned -n as a suffix.  It's unreasonable to
expect complete coverage, particularly initially and because the code is
still evolving.  Anything new is better than what we have now.

> In this case, it would be wise to explain the history of the relevant
> standard requirement (changed in C90 TC1 in response to DR#009, change
> failed to be applied to C99, resubmitted in DR#249 and will hopefully be
> fixed again in C99 TC2) even though the differences of wording aren't
> relevant to this particular testcase.  (Though I didn't include such an
> explanation in gcc.c-torture/compile/20010114-1.c, just a presumption of
> an understanding that the C90 TC1 wording was the correct one.)  At least
> note that the C99 text is wrong here and the correct text is that from C90
> TC1 and DRs #249.

Is this OK?

Neil.

	* decl-1.c: Update, add second test.


Index: decl-1.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/testsuite/gcc.dg/decl-1.c,v
retrieving revision 1.2
diff -u -p -r1.2 decl-1.c
--- decl-1.c	2002/02/12 09:02:04	1.2
+++ decl-1.c	2002/02/16 13:09:23
@@ -2,16 +2,28 @@
 
    Source: Neil Booth, 12 Feb 2002.
 
-   In the declaration of proc, x must be parsed as a typedef name
-   (6.7.5.3 p11).  */
+   In the declaration of proc, x must be parsed as a typedef name (C99
+   6.7.5.3 p11.  Also see C89 DR #009, which was erroneously ommitted
+   from C99, and resubmitted as DR #249: if in a parameter
+   declaration, an identifier can be read as a typedef name or a
+   paramter name, it is read as a typedef name).  */
 
 /* { dg-do compile } */
 
 typedef int x;
+typedef int y;
 int proc(int (x));	/* x is a typedef, param to proc is a function.  */
 int proc2(int x);	/* x is an identifier, param is an int.  */
 
+/* Parameter to proc3 is unnamed, with type a function that returns
+   int and takes a single argument of type function with one int
+   parameter returning int.  In particular, proc3 is not a function
+   that takes a parameter y that is a function with one int parameter
+   returning int.  8-)  */
+int proc3(int (y (x)));
+
 int main ()
 {
-  return proc (proc2);		/* { dg-bogus "integer from pointer" } */
+  proc (proc2);		/* { dg-bogus "integer from pointer" } */
+  return proc3 (proc);  /* { dg-bogus "incompatible pointer type" } */
 }



More information about the Gcc-patches mailing list