https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99576
--- Comment #8 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Adrian Perl from comment #7)
Again, thanks for working on this.
> Bootstrapping was successfull and the tests are currently running. Some of
> the tests have failed, but they don't seem to be related to coroutines.
On most platforms, at any given point in the cycle, there will be failing
tests...
> Should I test twice, with and without the patch, in order to see the actual
> impact?
... so ,yes, that is the usual approac.
there are some tools that help you compare the results.
I personally use:
${src}/contrib/test_summary > summ.txt
and then the same in the patched build tree ...
... and then compare the two summ.txt files side-by side using diff -> less.
(it is important that the same number of tests are executed of course, so the
numbers are relevant as well as the pass/fail). Your number for g++ should be
bigger by the ones added.
> Most of the test-applications attached and posted in the bug reports only
> log to stdout/stderr. Should I rewrite them and add assertions?
The usual mechanism is to do a test and to abort()*** on fail [an assert is
equivalent]. The reason for the abort() rather than, say, returning non-zero
from main is that when tests are conducted on remote embedded platforms, the
return value from main() might not be available.
***
For c++ tests, the extra of pulling in <cassert> or <cstdlib> is likely not
significant, but if you want to avoid that (it can make debugging easier to
reduce the number of headers pulled in) .. then you can use __builtin_abort();
