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.129.124]) by sourceware.org (Postfix) with ESMTPS id EB46E3858D35 for ; Wed, 18 Jan 2023 14:25:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EB46E3858D35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1674051933; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=JoR6ujFZQaQeLGYdgLdDTxfdkMfxHignZRQjwboIq9A=; b=RK9fPBzWHc6pZgPxZjjOmXepPO6ZO0n0jce8+Gy9aRmb7SnrzTScpxY+MuNGJY6lfnfbeU SohAFI7liOriAps7KgFJULWJpHxSnfHf0mVM8crVrgwufoAZc5PzTwEtDSX2BQA3meMMo5 i1UxznTbmE5TxBl5LPn1PxtAmnXGwMY= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-669-9UnwIjfSOAKW5jFpbB6rFg-1; Wed, 18 Jan 2023 09:25:29 -0500 X-MC-Unique: 9UnwIjfSOAKW5jFpbB6rFg-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 5439F857A88; Wed, 18 Jan 2023 14:25:29 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0B0DC2166B29; Wed, 18 Jan 2023 14:25:27 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 30IEPOTq1501294 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 18 Jan 2023 15:25:25 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 30IEPNCq1501293; Wed, 18 Jan 2023 15:25:23 +0100 Date: Wed, 18 Jan 2023 15:25:23 +0100 From: Jakub Jelinek To: Andreas Schwab Cc: Michael Matz , gcc-patches@gcc.gnu.org, Richard Biener , Jan Hubicka Subject: Re: [PATCH] lto: pass through -funwind-tables and -fasynchronous-unwind-tables Message-ID: Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, Jan 18, 2023 at 03:14:01PM +0100, Andreas Schwab wrote: > On Jan 18 2023, Michael Matz wrote: > > > So, it's quite clear that the option merging algorithm related to all this > > is somewhat broken, the global (or per function, or whatever) > > -funwind-tables option from hello.o doesn't make it correctly into the > > output (when -g is there). Adding -fexception makes it work because then > > the functions will have personalities and on LTO-read-in _that_ will > > implicitely enable funwind-tables again (which should have been enabled > > already by the option-read-in). > > My guess is that flag_unwind_tables is not yet set when .cfi_sections is > emitted (which is done by dwarf2out_assembly_start before compile starts). Well, the primary question for PerFunction/Optimization flag is what such flag means outside of any function. Because with such flags, it no longer is everything wants unwind tables (or asynchronous unwind tables), but perhaps some functions want that and others don't. So, do we for .cfi_sections want to know whether at least one of the functions in the TU (or partition for lto1) wants unwind tables / asynchronous unwind tables, or whether all of them do, something else? That isn't specific to LTO btw, one can compile say: -g -O2 -fasynchronous-unwind-tables -funwind-tables __attribute__((optimize ("no-asynchronous-unwind-tables,no-unwind-tables"))) int foo (int x) { return x; } __attribute__((optimize ("no-asynchronous-unwind-tables,no-unwind-tables"))) int bar (int x) { return x; } or -g -O2 -fno-asynchronous-unwind-tables -fno-unwind-tables __attribute__((optimize ("asynchronous-unwind-tables,unwind-tables"))) int foo (int x) { return x; } __attribute__((optimize ("asynchronous-unwind-tables,unwind-tables"))) int bar (int x) { return x; } Now, for non-LTO what you get in flag_asynchronous_unwind_tables or flag_unwind_tables when cfun is NULL is I think whatever has been set on the command line (or defaulted), which doesn't need to match any of the emitted functions. For LTO we currently get there just whatever has been defaulted. Neither of that will always match all the states of all the functions. Jakub