From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 57B7F385802F; Thu, 3 Aug 2023 14:39:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 57B7F385802F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1691073541; bh=a/Js8j5si3vhvnUJieRda4+CgvQoZeEMwUndR1y/xCw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=sqHFG7ecZDcwhpHBQyaw1rfA1NN4XtepAlIkPTZFR/ALqbn7LYryPs0rTBLo4jxRy nSUKTg77F8FpOS8mBcwZfRGhlbmVayc/yibg337z66caaIgZo6spaEgZ7BHXujGJZu l8YA6tp3xqdNmLUrHXlxaPu1po2r29cepf31oK1g= From: "matz at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/110728] should __attribute__((cleanup())) callback get invoked for indirect edges of asm goto Date: Thu, 03 Aug 2023 14:38:58 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: EH, wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: matz at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D110728 Michael Matz changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |matz at gcc dot gnu.org --- Comment #9 from Michael Matz --- Just for completeness: I agree with Andrew that the initial code example in comment #0 doesn't show any problem. The edge from asmgoto to l0 doesn't c= ross the scope of the variable, hence no cleanups should be run. The cleanup call that is there is from the edge that leaves the function scope before return, and it's placed correctly. But the example from comment #8 indeed shows a problem with asm-goto. But = it may be impossible to fix. That has to do with how we need to (possibly) sp= lit critical edges, which changes label identity, which in turn might actually be the thing that's required by the asmgoto. Like in such situation: ---------- extern int printf (const char *, ...); extern void doit(void *p); void foo (int cond) { { int x __attribute__((cleanup(doit))); if (cond) asm goto("# A %l0"::::out); else asm goto("# B %l0"::::out); } printf("..."); out: } ---------- The calls to doit need to be emitted on the two edges asm1->out and asm2->o= ut, but must _not_ be emitted on the fallthrough printf->out (of course, because the cleanup was already done on the edge x-scope->printf). The only way to do that is by splitting those edges which introduces new labels: { { int x; if (cond) asm goto("# A %l0"::::out1); else asm goto("# B %l0"::::out2); doit(); } printf("..."); out: return; out1: doit(); goto out; out2: doit(); goto out; } (In this easy example we could save ourself by realizing that the out1 and = out2 code sequences are the same, and hence could get away with just emitting one new label instead of two. In general that's not possible.) That's the CFG manipulation that needs happening. The question is what it does to the asmgoto: both now receive different labels, whereas before they received the same. If whatever the asm does relies on the identity of these label then this will break things. Now, asm gotos were specifically introduced to be able to jump to stuff, not to capture the identity of labels/code-addresses (as is done for instan= ce in the linux kernel alternative mechanism), so it may be fine to do the edge splitting and associated renaming of labels. But that needs to be a consci= ous decision.=