From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 7DFD93945C1F for ; Tue, 22 Feb 2022 16:56:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7DFD93945C1F Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-32-oUqkn0d3OuqShjq8BHRpug-1; Tue, 22 Feb 2022 11:56:47 -0500 X-MC-Unique: oUqkn0d3OuqShjq8BHRpug-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 005B3800422 for ; Tue, 22 Feb 2022 16:56:47 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.125]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 83F70837B5; Tue, 22 Feb 2022 16:56:36 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 21MGuXRk525959 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 22 Feb 2022 17:56:34 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 21MGuXjt525958; Tue, 22 Feb 2022 17:56:33 +0100 Date: Tue, 22 Feb 2022 17:56:33 +0100 From: Jakub Jelinek To: Andrew MacLeod Cc: gcc-patches , Aldy Hernandez Subject: Re: [PATCH 0/2] tree-optimization/104530 - proposed re-evaluation. Message-ID: Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2022 16:56:51 -0000 On Tue, Feb 22, 2022 at 11:39:41AM -0500, Andrew MacLeod wrote: >  I'd like to get clarification on some subtle terminology. I find I am > conflating calls that don't return with calls that may throw, and I think > they have different considerations. > > My experiments with calls that can throw indicate that they always end a > basic block.  This makes sense to me as there is the outgoing fall-thru edge > and an outgoing EH edge.  Are there any conditions under which this is not > the case? (other than non-call exceptions) Generally, there are 2 kinds of calls that can throw, those that can throw internally and those can throw externally (e.g. there are stmt_could_throw_{in,ex}ternal predicates). Consider e.g. void foo (); struct S { S (); ~S (); }; void bar () { foo (); foo (); } void baz () { S s; foo (); foo (); } void qux () { try { foo (); } catch (...) {} } the calls to foo in bar throw externally, if they throw, execution doesn't continue anywhere in bar but in some bar's caller, or could just terminate if nothing catches it at all. Such calls don't terminate a bb. In baz, the s variable needs destruction if either of the foo calls throw, so those calls do terminate bb and there are normal fallthru edges from those bbs and eh edges to an EH pad which will destruct s and continue propagating the exception. In qux, there is explicit try/catch, so again, foo throws internally, ends bb, has an EH edge to EH landing pad which will do what catch does. That is EH, then there are calls that might not return because they leave in some other way (e.g. longjmp), or might loop forever, might exit, might abort, trap etc. I must say I don't know if we have any call flags that would guarantee the function will always return (exactly once) if called. Perhaps ECF_CONST/EFC_PURE without ECF_LOOPING_CONST_OR_PURE do? Jakub