[Bug c++/99576] [coroutines] destructor of a temporary called too early within co_await expression

["iains at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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();