Re: [PATCH] Add ggc-tests.c

[Jeff Law <law at redhat dot com>]

On 06/06/2016 03:31 PM, David Malcolm wrote:
> Jeff approved an earlier version of this (as
> unittests/test-ggc.c):
>   https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03306.html
> > Not terribly happy with that counter to used to create a big list
> > to detect recursion. But I'm not offhand sure how to avoid without
> > exposing more of the ggc system that is wise.
> >
> > OK if/when prereqs are approved. Minor twiddling if we end up
> > moving it elsewhere or standardizing/reducing header files is
> > pre-approved.
>
> This version moves it to gcc/ggc-tests.c and ports it to the new
> -fself-test approach.
>
> For now, I also reduced the count within
>   TEST_F (ggc_test, chain_next)
> from 2 million to 10, to avoid slowing down the test (though the
> former takes only about 0.5s on my box).
>
> I've also fixed things so that it works with both checked and unchecked
> builds.  Note that the GTY roots within ggc-tests.c are wrapped with
>   #if CHECKING_P
> which implies that PCH files would be incompatible between release vs
> checked builds (I'm not sure whether or not that's already the case).
I wouldn't expect PCH files to be compatible across release vs checked 
builds.  It might work, but that'd likely be more accident than design 
(though I am trying to squash out cases where structures change their 
lengths based on things like ENABLE_CHECKING).


> I've also added various new tests since Jeff's review, for:
>   * GTY((length)),
>   * unions, and
>   * GTY((user))
>
> Successfully bootstrapped&regrtested on x86_64-pc-linux-gnu.
>
> OK for trunk?
>
> gcc/ChangeLog:
> 	* Makefile.in (OBJS): Add ggc-tests.o.
> 	(GTFILES): Add ggc-tests.c.
> 	* ggc-tests.c: New file.

> +
> +static void
> +test_chain_next ()
> +{
> +  /* 2 million nodes (and thus the same number of stack frames) ought
> +     to be deep enough to crash if gengtype has created something
> +     that recurses.
> +
> +     This length reliably causes the test to segfault without the
> +     chain_next/prev optimization on this box (Fedora 20 x86_64 with 128GB
> +     of RAM), but causes this test to take about 0.5s, dominating the time
> +     taken by the overall testsuite.
> +
> +     We could perhaps lower this by not increasing the stack size so much
> +     in toplev.c, or perhaps reducing the stack size when running this
> +     testcase.  */
> +  const int count = 10; // 2000000;
ISTM like you need to update the comment.  And the trailing // 2000000 
should be eliminated.

I'm just not sure how to really test for this properly.  I'd be tempted 
to remove it.

OK with the comment fixes for test_chain_next.

jeff