From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 1C2183857838; Wed, 19 Jul 2023 16:46:39 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1C2183857838 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1689785199; bh=riG+kW7LikjdQEgB/xej1ONbSBoZctVbfXw/iXNtab8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=oLB+JZ/OAnFZ9Giau65dqzYCGWBGMWGDL/3axM/Bk+wOFCpjUzwg+wD+1rcBbzpnN vOUo+/8VCZ5t7TcXEWheBXFVnieNgB39rp7R5DhCszhPwZqUagbrg6GuKund6w7N2w tIIk0MIz3hY1TJuW+HIyGd1r1wG219JinMEyfZ20= From: "ndesaulniers at google dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/110728] should __attribute__((cleanup())) callback get invoked for indirect edges of asm goto Date: Wed, 19 Jul 2023 16:46:38 +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: ndesaulniers at google dot com 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: 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 --- Comment #7 from Nick Desaulniers --- (In reply to Andrew Pinski from comment #1) > I suspect PR 91951 is the same really. PR 91951 seems to be about a missing diagnostic dependent on optimization level. This bug report is more so a question about codegen. (In reply to Andrew Pinski from comment #2) > Techincally x does not go out of scope until the } so I don't see how this > would act any other way. Compare the codegen with my example vs replacing the `asm goto (..., l0);` = with `goto l0;`. With `goto`, the destructor is invoked before taking the backward edge. Wi= th `asm goto` it is not. That inconsistency leads me to think there might be a bug (with `asm goto`). (In reply to Andrew Pinski from comment #4) > Oh and computed goto has a similar issue too (PR 37722 which is for C++ > deconstructors but cleanup is the same idea there). Right, that came up in our discussions, too. I think the difference may be that with `asm goto` we have the list of labels of possible jump targets and thus possible edges. With computed goto ("indirect goto") we don't. So I t= hink it makes sense to not run destructors for computed goto, and perhaps the documentation should be made more explicit about that case (then PR 37722 closed as "Working as intended"). (In reply to John McCall from comment #5) > > If this gets changed in GCC, I'd be happy to modify clang to match that= updated behavior. >=20 > Policy-wise, I don't think clang would accept a patch making this UB > (effectively what not calling the destructor/cleanup means) instead of > ill-formed unless a standards body forced us to. Not calling the > destructor/cleanup seems like clearly undesirable behavior, and if we can > define that away in the compiler with relative ease, we should. Let me clarify. If GCC were change behavior of `asm goto` to invoke the destructor/cleanup function before the backwards edge of `asm goto`, I would submit a patch to clang to implement that behavior as well. I think we're (John and I) in agreement that the destructors should be run.=