In 5.4.2.1 in the C standard, there's a list of "translation limits".
The GNU coding standard says that a GNU program should "Avoid
arbitrary limits" and so does the C standard, and indeed GCC is
supposed to avoid most of these limits. (There are one or two limits
that are necessary to prevent run-away in the preprocessor.)
So, this patch adds a number of testcases which verify that there is
at least one program which significantly exceeds a minimum limit in
the C standard and which GCC can compile.
I'm a little disappointed in this particular group of testcases. I
originally wrote them for GCC 4.0, running on a 450Mhz G4 with 256Mb
of RAM, and they all ran correctly and reasonably quickly. When I
came to re-check them against mainline, on a 2Ghz G5 with 512Mb of RAM
(not a new or state-of-the-art machine), many of them didn't work at
all and some were much slower. The ones that didn't work at all
appear to be due to the new recursive-descent parser needing much more
stack space; I'm not sure about the slowdowns yet. I 'fixed' the
problem by reducing the problematic testcases to 10,000 instead of the
original 100,000. I think it's important to have them in dejagnu
so that they don't regress further.
The limits tested are:
* 127 nesting levels of blocks: limits-blocks.c (10,000)
* 12 pointer, array, and function declarators (in any combinations)
modifying an arithmetic, structure, union, or incomplete type in a
declaration: limits-pointer.c (10,000)
* 63 nesting levels of parenthesized declarators within a full
declarator: limits-declparen.c (10,000)
* 63 nesting levels of parenthesized expressions within a full
expression: limits-exprparen.c (10,000)
* 63 significant initial characters in an internal identifier or a
macro name: limits-idinternal.c (1,000,000)
* 31 significant initial characters in an external identifier:
limits-idexternal.c (10,000)
* 4095 external identifiers in one translation unit:
limits-externalid.c (100,000)
* 511 identifiers with block scope declared in one block:
limits-blockid.c (100,000)
* 127 parameters in one function definition: limits-fndefn.c (100,000)
* 127 arguments in one function call: limits-fnargs.c (10,000)
* 4095 characters in a character string literal or wide string literal
(after concatenation): limits-stringlit.c (100,000,000)
[I believe this also tests "65535 bytes in an object (in a hosted
environment only)". It probably shouldn't.]
* 1023 case labels for a switch statement (excluding those for
any nested switch statements): limits-caselabels.c (100,000)
* 1023 members in a single structure or union: limits-structmem.c (10,000)
* 1023 enumeration constants in a single enumeration:
limits-enumconst.c (100,000)
* 63 levels of nested structure or union definitions in a single
struct-declaration-list: limits-structnest.c (10,000)
The missing tests are all preprocessor-related, and unlike these tests
might need to be fairly large files:
* 63 nesting levels of conditional inclusion
* 4095 macro identifiers simultaneously defined in one preprocessing
translation unit
* 4095 characters in a logical source line
* 15 nesting levels for #included files
I believe there are tests for some of these with the preprocessor
testcases.
For strict conformance, you really should try to link all of these
testcases into a single executable, but these tests are just trying to
test the compiler (and, a little bit, the assembler) so I didn't do
that.
Tested by running 'make check-gcc' for just these files.
--
- Geoffrey Keating <geoffk@apple.com>
===File ~/patches/gcc-testsuite-limits.patch================
2007-04-12 Geoffrey Keating <geoffk@apple.com>