From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 639D93830B2D; Sat, 26 Nov 2022 16:40:49 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 639D93830B2D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1669480849; bh=PruNw2X6O6KxRiuD6eOQ0jiRGUlT/7B+KmT70bPz000=; h=From:To:Subject:Date:In-Reply-To:References:From; b=x5d2PtrRbug+AIdMdPqPJTsbtHWWnTSNnVPwgiX+wdmDsR22Sm+BeNmLAQAgoqmcU TyQ/ctpsahx9QD/g7gXvaCz6x8dZ2DrSDcM4+cd9iUXPKp845KX1MMHm2F1krRWKoM uYDxrR8GxzBSQyjzh1SBLyqxdVB8WPlPP+wm575g= From: "iains at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/99576] [coroutines] destructor of a temporary called too early within co_await expression Date: Sat, 26 Nov 2022 16:40:49 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 10.2.1 X-Bugzilla-Keywords: C++-coroutines, wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: iains at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D99576 --- Comment #8 from Iain Sandoe --- (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 actu= al > impact?=20 ... 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=20 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 t= he 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 or 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= ();=