This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH v2 0/9] Separate shrink-wrapping
On Mon, Sep 12, 2016 at 10:49:46AM -0600, Jeff Law wrote:
> On 09/09/2016 02:56 PM, Segher Boessenkool wrote:
> >On Fri, Sep 09, 2016 at 12:57:32PM -0600, Jeff Law wrote:
> >>I think the lack of test coverage is something we'll want to address.
> >
> >Building and running the compiler, the various target libraries, and the
> >testsuite is more than enough coverage for correctness in my opinion --
> >I cannot make up anything that is not already in there. No doubt some
> >PR will show up later, and we can (and should) of course add that then.
> >
> >For checking whether it makes "smart" decisions, I'll make some really
> >simple testcases that will not fail for random reasons all the time.
> I'm moving more and more towards wanting tests for new features.
> There's no reason why verification of basic behavior shouldn't be part
> of the feature patch itself.
Yes, but as I said, this is used millions of times during bootstrap
already, and at least *I* cannot think of more complex structures that
would fail. If any show up we can add them as regression tests.
> I suspect the biggest problem with testing something like separate
> shrink wrapping is making sure the test is stable over time -- and
> that's a legitimate concern.
Yes exactly.
> But it ought to be do-able in one form or another,
Yes, as I promised, I'll make up some trivial tests.
> particularly since we have control over the debug dumps.
I'm not a big fan of using the debug dumps in the testsuite -- very
often tests break because you changed something in the dump. Debug
dumps are for debug, not for testing.
If we get to the point where we generically can use some piece of RTL
as input and just run one pass on it, that would be nice. But we're
not there yet, and the kind of "unit tests" where you just write all
code twice and essentially only test if the test is correct: no thanks.
Segher