Re: Recent libstdc++-v3 regressions (PCHs related?!?)

[David Malcolm <dmalcolm at redhat dot com>]

On Tue, 2013-08-20 at 10:41 -0400, David Malcolm wrote:
> On Tue, 2013-08-20 at 14:03 +0200, Paolo Carlini wrote:
> > Hi,
> > 
> > sorry it the issue is by now well known but... I see many libstdc++-v3 
> > regressions on at least x86_64-linux. When running the libstdc++-v3 
> > testsuite (which uses PCHs) one gets tons of new fails like the below. 
> > That's annoying, a lot of confusing noise.
> > 
> > Thanks!
> > Paolo.
> > 
> > PS: CC-ing two "random" ;) people lately very active.
> 
> Sorry about this - looking at the backtrace this could well be due to
> me, specifically r201865, which moved the gcc::pass_manager and all the
> passes into the GC heap (so that we can then move GC-owned per-pass
> state into the pass instances).  This would require pch files to be
> regenerated, but presumably the test suite does this, right?
> 
> I did rerun the bootstrap and regression tests before committing (based
> on clean builds with and without the patches), but presumably something
> unexpected is happening.
> 
> I'm investigating now.

I've been erroneously running the test suite as:

  make check

but looking at http://gcc.gnu.org/contribute.html#testing
I now realise that I should be running:

  make -k check

and that it's only been running the gcc tests, stopping when they don't
all pass - the "-k" flag is needed:

$ find test/*/build -name "*.sum"
test/control/build/gcc/testsuite/gcc/gcc.sum
test/control/build/gcc/testsuite/g++/g++.sum
test/control/build/gcc/testsuite/gfortran/gfortran.sum
test/control/build/gcc/testsuite/objc/objc.sum
test/experiment/build/gcc/testsuite/gcc/gcc.sum
test/experiment/build/gcc/testsuite/g++/g++.sum
test/experiment/build/gcc/testsuite/gfortran/gfortran.sum
test/experiment/build/gcc/testsuite/objc/objc.sum

Sorry about this.  I've updated my scripts to fix this, and am rerunning
(I hope) the full set of test suites now.

It's probably worth updating that page to spell out that -k is
necessary.

> (FWIW, if we have to back out r201865, I believe we also have to back
> out r201864).

Given that I don't yet have a fix and that my testing has been
incomplete, I've gone ahead and backed out both changes as r201887.

Sorry again.
Dave