Re: [testsuite, ada] Convert ACATS to DejaGnu (PR testsuite/37703)

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Tue, 1 Feb 2011, Dave Korn wrote:

> On 01/02/2011 17:24, Joseph S. Myers wrote:
> 
> > For the general issue: a slow test appears to have served its purpose by 
> > showing up a (target-specific) bug in the compiler.  And in general you 
> > need to consider whether a resource-hungry test is actually showing up a 
> > bug and should not be so resource-hungry, before reducing the test size or 
> > only running it conditionally.  (You might still reduce it after finding 
> > it shows a bug - but only after filing that bug in Bugzilla; not simply 
> > blindly presume that the test is too big for the testsuite.)
> > 
> 
>   How many layers of nested parentheses /should/ we be able to support, in how
> much memory?  limits-exprparen.c keeps growing...
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31827

I'd say we should support as many as allowed by available memory.  (More 
than 4GB of them even, on a 64-bit system with enough memory.)  Hence the 
suggestion of -fsplit-stack: some code seems natural enough for humans to 
write in a recursive way, and then you want the compiler/linker to be 
smart about stopping this from causing problems with deep recursion.  (If 
-fsplit-stack isn't the right approach, maybe some other C/C++ extension 
to tell the compiler to turn a particular set of mutually recursive 
functions into a non-recursive function using some specified allocator 
would be appropriate - for this and any other case where deep recursion is 
possible in GCC.)  This does not mean we should put a test with 4GB of 
nested parentheses in the testsuite (except in a set of tests that are 
only run if you declare you want to run huge tests and have a huge amount 
of memory)!

The principle of being limited only by available memory applies more 
generally and is in accord with standard GNU principles; for example, 
TREE_STRING_LENGTH should not be an int because that imposes a 2GB-1 limit 
on string constants which should not be needed if both host and target are 
64-bit.  Though in some cases eliminating limits might make the common 
cases take more time and memory (and so would need to be conditioned on 
configure options), and eliminating such limits is certainly one of the 
harder cleanups in GCC (difficulty in avoiding potential integer overflows 
is intrinsic to programming in C or C++, it's not anything specific to the 
GCC code base), as well as being one with less obvious utility in 
practice.

-- 
Joseph S. Myers
joseph@codesourcery.com