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

--- Comment #7 from Nick Desaulniers <ndesaulniers at google dot com> ---
(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.  With
`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 think
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.
> 
> 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.

Reply via email to