On Fri, Jun 21, 2013 at 11:18 AM, John McCall <[email protected]> wrote: > On Jun 21, 2013, at 1:30 AM, Chandler Carruth <[email protected]> wrote: > > On Thu, Jun 20, 2013 at 6:15 PM, John McCall <[email protected]> wrote: >> >> On Jun 20, 2013, at 12:37 AM, Chandler Carruth <[email protected]> >> wrote: >> >> On Thu, Feb 7, 2013 at 4:37 PM, Richard Smith <[email protected]> >> wrote: >>> >>> cfe/trunk/test/Modules/cxx-many-overloads.cpp >> >> >> Hate to dig up this test, but I wanted to mention that this is the single >> slowest test in the regression test suite for me at 28.84s... Wondered if >> you had any ideas about making it cheaper. >> >> >> Maybe it would just more appropriate in a different test suite? I believe >> there are a number of bots that run clang-tests, and getting 100% platform >> coverage doesn't seem completely imperative here. > > > My suspicion (which is nothing more as I've not investigated) is that this > is testable with a reasonable cheap test, and having in the basic 'make > check' pattern seems worthwhile on the whole. But certainly if the first > proves to not be the case, we shouldn't keep it here just for the second... > > > If it can be made efficient, then absolutely it can and should stay. But > 'make check' is never going to be an exhaustive test suite, and tying up a > core for a long time (even on your presumably quite beefy machine) in a > deliberate stress test feels like something that really belongs in a > secondary test suite like clang-tests, especially to test a fix that > honestly does not seem particularly fragile.
Yes, I agree. I'd even be happy to drop the test case entirely, if no-one objects; it was only ever indirectly testing the fix. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
