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