From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 552103858439; Wed, 19 Jul 2023 17:16:55 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 552103858439
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1689787015;
	bh=xwFS8Yd5rZhNk3QnkZMycs/TLaSx5ru4aJN6S1yQn7E=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=kEIGpsuKuuUXldnjfCaOSOYH4XyWsD/XYis8WrSw3iH77ng7BYC5Bl/gXtlzd1N66
	 hreTpe3gAKX6LdQTB4cgnBfEF3B2AktfKYb/kuaLB9O1QQjfpFt9AqJeIR4Sn3Jtsx
	 IN4lS/aJGf9Q6diycDDqy72NMzqfdMiE3hA6novU=
From: "rjmccall at gmail dot com" <gcc-bugzilla@gcc.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: Wed, 19 Jul 2023 17:16:55 +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: rjmccall at gmail 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: <bug-110728-4-KuAKVv0zQj@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-110728-4@http.gcc.gnu.org/bugzilla/>
References: <bug-110728-4@http.gcc.gnu.org/bugzilla/>
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: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D110728

--- Comment #8 from John McCall <rjmccall at gmail dot com> ---
> 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.

Ah, thank you, I understand what you're saying now.  Yes, we would take tha=
t.

I think this test case might be a little more illuminating and separates out
the issue of the back-edge and the uninitialized variable:
https://godbolt.org/z/doG7414va

```
#include <malloc.h>

#define GOTO 1
#define COMPUTED_GOTO 2
#define ASM_GOTO 3

#define CASE ASM_GOTO

static void free_from(int **ptr) {
    free(*ptr);
}

int test() {
#if CASE =3D=3D COMPUTED_GOTO
    void *lbl =3D &&label;
#endif
    if (1) {
        __attribute__((cleanup(free_from))) int *p =3D calloc(sizeof(int), =
1);
#if CASE =3D=3D GOTO
        goto label;
#elif CASE =3D=3D COMPUTED_GOTO
        goto *lbl;
#elif CASE =3D=3D ASM_GOTO
        asm goto("<<< asm goto %l0 >>>"::::label);
#endif
    }
    label:
    return 0;
}
```

GCC produces this output for CASE =3D=3D ASM_GOTO (stripping the .LFB label=
s):

```
test:
        push    rbp
        mov     rbp, rsp
        sub     rsp, 16
        mov     esi, 1
        mov     edi, 4
        call    calloc
        mov     QWORD PTR [rbp-8], rax
        <<< asm goto .L3 >>>
        lea     rax, [rbp-8]
        mov     rdi, rax
        call    free_from
.L3:
        mov     eax, 0
        leave
        ret
``

It does something similar for CASE =3D=3D COMPUTED_GOTO.  In both cases, th=
e branch
avoids the cleanup with no diagnostic.  But it does the right thing with CA=
SE
=3D=3D GOTO.=