From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=cVsp=5Q=gmail.com=richard.guenther@sourceware.org>
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132])
	by sourceware.org (Postfix) with ESMTPS id 9D2DC3858C2C
	for <gcc-patches@gcc.gnu.org>; Thu, 19 Jan 2023 07:14:37 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9D2DC3858C2C
Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com
Received: by mail-lf1-x132.google.com with SMTP id cf42so1949049lfb.1
        for <gcc-patches@gcc.gnu.org>; Wed, 18 Jan 2023 23:14:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=wciDOYi9cK08y9XJLaq34l+Xr28cX1Gc6tSopOtO7r4=;
        b=I2fLZ7iwJppJf7FlbdqL57KxwmKUqT/5xGt8IvES9oSz89G0jRV3RXoncq6HSTD+S5
         +atY9XNAlVJHCJFFU+3ykTnn98ZVuqjeWQA/h1IzfVxFM0FMQ6DE96gvRXnPZjqg5QFF
         rVv7+AjCzXHQ+PDwPAKsa7UvmaYCF5oMDahXHxBdCt+pSneL0dbIosHPlASdxEud1bgK
         U5Cxvsr02a1ut9/GC39V6KFeLJBtMLk8Hc3tfZ7fj/mWPcAOpg1k8hQL9oKfVOIJVGWU
         W/6G3YJKpSphR23/iaFBct38MskutWHdCyS1JCGMCt9DkzKxfYShNl4DnFmFipe+0z4K
         PasA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=wciDOYi9cK08y9XJLaq34l+Xr28cX1Gc6tSopOtO7r4=;
        b=4FEcJZaJLJN2CMl7VBmZcjAIgPqiN2Zd65YLmCUHfNOpTo18yaNgdKj6Yu2Du1vKw1
         OK4SINaup6jiHz/0Sp7Cq1t8YoTWU0HzjzkQmtTMYhc/98ha6SXMNbGZuoSxnkc6X4+O
         GSTNGziN4QP4fzSg/hwjCbEbJ2R4lmoPf4nhL/txKQTX7z9mMQq3Hpyxh9bB3cixVxvP
         97BfVhmgxObZtR519dI0VQDCovTM38dhTwgV1ghdILK65Yztu3a8ehw0YNCO6E+ISqDv
         ITZz8vGwmajj/a1d5f46exafb+P4Yv/7uoBBOkfXbPCUYj5OIPAAmgGhAjbf69CDbGi2
         /KOw==
X-Gm-Message-State: AFqh2koO6ag2Q2zLsCyuBf8taIkLwDJkM+O0W9xUky+sJj8yp7AinjC5
	rV1gwU16nkIqXa53IT2URLfoMWa6dGIRo7z0E3c=
X-Google-Smtp-Source: AMrXdXvJPNtY1gAWigFWx+/M2To4tuspa1uc4+DfKRAullu/FxGBUXPinO9Mb2v978GYQ78kSBRmhi0M4SmZS+ohgf8=
X-Received: by 2002:a19:700e:0:b0:4cb:3ca6:1d1a with SMTP id
 h14-20020a19700e000000b004cb3ca61d1amr457953lfc.448.1674112475844; Wed, 18
 Jan 2023 23:14:35 -0800 (PST)
MIME-Version: 1.0
References: <mvmlem0ywoy.fsf@suse.de> <CAFiYyc1+6W=JBu0RXY-NBjK2RgCD9+5LyD1u7-LJvZDZ_q9+_w@mail.gmail.com>
 <mvm8ri0ytig.fsf@suse.de> <Y8fYd6LKBxVB2eAs@tucnak> <mvm4jsoyqgy.fsf@suse.de>
 <Y8fnlIJBpOdyujtp@tucnak> <mvmzgagxbih.fsf@suse.de> <Y8fqRWPkL8EhTHbI@tucnak>
 <mvmtu0oxajh.fsf@suse.de> <Y8gLIJTOxL2zI0v9@kam.mff.cuni.cz>
In-Reply-To: <Y8gLIJTOxL2zI0v9@kam.mff.cuni.cz>
From: Richard Biener <richard.guenther@gmail.com>
Date: Thu, 19 Jan 2023 08:14:23 +0100
Message-ID: <CAFiYyc1KUaA17FpEAVsXYBXnC30a7CgHysK3f93jTS7taDf7ug@mail.gmail.com>
Subject: Re: [PATCH] lto: pass through -funwind-tables and -fasynchronous-unwind-tables
To: Jan Hubicka <hubicka@ucw.cz>
Cc: Andreas Schwab <schwab@suse.de>, Jakub Jelinek <jakub@redhat.com>, gcc-patches@gcc.gnu.org
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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: <gcc-patches.gcc.gnu.org>

On Wed, Jan 18, 2023 at 4:07 PM Jan Hubicka <hubicka@ucw.cz> wrote:
>
> > No unwind tables are generated, as if -funwind-tables is ignored.  If
> > LTO is disabled, everything works as expected.
> I think it is because dwaf2out_do_eh_frame is called out of function
> context at the end of compilation. At that time cfun is NULL
> and the flag is read from global settings that are wrong.
> So we need to bookkeep if we saw function that needs EH tables and not.

I think we do that with the do_eh_frame variable which was introduced to
fix a similar problem (PR81351).  But then dwarf2out_do_eh_frame seems
to be used both at a function and at the TU level and the latter now should
check do_eh_frame?  (and not be called early).  That is, the caller in
dwarf2out_do_frame wants to check that variable.

I see the first invocation of the function with cfun == null from c_cpp_builtins
but all others seem to have cfun set?

Richard.

> Honza
> >
> > --
> > Andreas Schwab, SUSE Labs, schwab@suse.de
> > GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> > "And now for something completely different."