From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6309139F7C87; Thu, 12 Nov 2020 09:48:39 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6309139F7C87 From: "cvs-commit at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/97790] constexpr evaluation reports false positive memory leak Date: Thu, 12 Nov 2020 09:48:39 +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: 11.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jakub 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 09:48:39 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D97790 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:fc531c2ed3ce456efca946e995544b216b3c16df commit r11-4936-gfc531c2ed3ce456efca946e995544b216b3c16df Author: Jakub Jelinek Date: Thu Nov 12 10:46:04 2020 +0100 c++: Fix up constexpr CLEANUP_POINT_EXPR and TRY_FINALLY_EXPR handling [PR97790] As the testcase shows, CLEANUP_POINT_EXPR (and I think TRY_FINALLY_EXPR too) suffer from the same problem that I was trying to fix in r10-3597-g1006c9d4395a939820df76f37c7b085a4a1a003f for CLEANUP_STMT, namely that if in the middle of the body expression of those stmts is e.g. return stmt, goto, break or continue (something that changes *jump_target and makes it start skipping stmts), we then skip t= he cleanups too, which is not appropriate - the cleanups were either queue= d up during the non-skipping execution of the body (for CLEANUP_POINT_EXPR),= or for TRY_FINALLY_EXPR are relevant already after entering the body block. > Would it make sense to always use a NULL jump_target when evaluating > cleanups? I was afraid of that, especially for TRY_FINALLY_EXPR, but it seems that during constexpr evaluation the cleanups will most often be just very simple destructor calls (or calls to cleanup attribute functions). Furthermore, for neither of these 3 tree codes we'll reach that code if jump_target && *jump_target initially (there is a return NULL_TREE much earlier for those except for trees that could embed labels etc. in it a= nd clearly these 3 don't count in that). 2020-11-12 Jakub Jelinek PR c++/97790 * constexpr.c (cxx_eval_constant_expression) : Don't pass jump_targ= et to cxx_eval_constant_expression when evaluating the cleanups. * g++.dg/cpp2a/constexpr-dtor9.C: New test.=