From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id B3799385AE4F for ; Tue, 2 Aug 2022 12:23:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B3799385AE4F Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id EDDE313D5; Tue, 2 Aug 2022 05:23:10 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.37]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CA4EC3F67D; Tue, 2 Aug 2022 05:23:09 -0700 (PDT) From: Richard Sandiford To: Philipp Rimmele via Gcc Mail-Followup-To: Philipp Rimmele via Gcc , Philipp Rimmele , richard.sandiford@arm.com Cc: Philipp Rimmele Subject: Re: try_finally_expr in must_not_throw_expr References: Date: Tue, 02 Aug 2022 13:23:08 +0100 In-Reply-To: (Philipp Rimmele via Gcc's message of "Sun, 31 Jul 2022 14:25:35 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-46.9 required=5.0 tests=BAYES_00, KAM_DMARC_NONE, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2022 12:23:12 -0000 Philipp Rimmele via Gcc writes: > Hi, > > i'm developing a GCC-Plugin. And i don't understand why there is a "try_finally_expr" in a must_not_throw-Area in my AST. It happens in the destructors. > Here is my AST: > function_decl Exception::__dt_base > 1: must_not_throw_expr(->void_type{void})[42] > 0: statement_list(->void_type{void}) > 0: bind_expr(->void_type{void})[42] > 1: statement_list(->void_type{void}) > 0: cleanup_point_expr(->void_type{void})[42] > 0: expr_stmt(->void_type{void}) > 0: convert_expr(->void_type{void}) > 0: modify_expr(->pointer_type->pointer_type{__vtbl_ptr_type}->function_type->integer_type{int}) > 0: component_ref(->pointer_type->pointer_type{__vtbl_ptr_type}->function_type->integer_type{int}) > 0: indirect_ref(->record_type{Exception}) > 0: nop_expr(->pointer_type->record_type{Exception}) > 0: parm_decl(->pointer_type->record_type{Exception}) : this > 1: field_decl(->pointer_type->pointer_type{__vtbl_ptr_type}->function_type->integer_type{int}) > 1: pointer_plus_expr(->pointer_type->pointer_type{__vtbl_ptr_type}->function_type->integer_type{int}) > 0: addr_expr(->pointer_type->pointer_type{__vtbl_ptr_type}->function_type->integer_type{int}) > 0: var_decl(->array_type->pointer_type{__vtbl_ptr_type}->function_type->integer_type{int}) : _ZTV9Exception > 1: integer_cst : 16 : 1 > 0: try_finally(->void_type{void})[42] > 0: statement_list(->void_type{void}) > 1: modify_expr(->void_type{void}) > 0: indirect_ref(->record_type) > 0: nop_expr(->reference_type->record_type) > 0: parm_decl(->pointer_type->record_type{Exception}) : this > 1: constructor(->record_type) > 2: block > 0: label_expr(->void_type{void})[42] > 0: label_decl(->void_type{void}) : > > What is the reason for this? There should no Exception be thrown, so why handle it with a try_finally-Expression? I'm currently using GCC-8.2.0. > I would be realy glad if you could answer me this question. And if you can give me some examples, where the try_finally-expression is also used, it would be realy helpfull. I'm not an expert on this by any means, but since no-one else has replied yet... I suspect it's simpler to use try_finally whenever something needs to be run at the end of a scope, regardless of whether the scope ends through fallthrough, breaking, continuing, or exceptions. To put it another way: try_finally at this stage doesn't guarantee that exception handling will actually be needed. For example: try { int i = 1; int j = 2; if (i == j) foo (); } finally ... starts out with a potentially-throwing call to foo, but it (and the possibility of an exception) will get optimised away later. It probably didn't seem worthwhile having the frontend do a similar but separate analysis of whether statements might throw. Thanks, Richard