aboutsummaryrefslogtreecommitdiff
path: root/flang/lib/Frontend/CompilerInvocation.cpp
diff options
context:
space:
mode:
authorChuanqi Xu <yedeng.yd@linux.alibaba.com>2023-08-23 16:37:21 +0800
committerChuanqi Xu <yedeng.yd@linux.alibaba.com>2023-08-23 16:51:53 +0800
commit7037331a2f05990cd59f35a7c0f6ce87c0f3cb5f (patch)
tree7f1783a03e6aaf0d8a139bd7813c582b3360d841 /flang/lib/Frontend/CompilerInvocation.cpp
parentef0b8cf3f46b65532a3101c9e3dbab41e5d77db4 (diff)
downloadllvm-7037331a2f05990cd59f35a7c0f6ce87c0f3cb5f.zip
llvm-7037331a2f05990cd59f35a7c0f6ce87c0f3cb5f.tar.gz
llvm-7037331a2f05990cd59f35a7c0f6ce87c0f3cb5f.tar.bz2
[Coroutines] [CoroElide] Don't think exceptional terminator don't leak coro handle unconditionally any more
Close https://github.com/llvm/llvm-project/issues/59723. The fundamental cause of the above issue is that we assumed the memory of coroutine frame can be released by stack unwinding automatically if the allocation of the coroutine frame is elided. But we missed one point: the stack unwinding has different semantics with the explicit coroutine_handle<>::destroy(). Since the latter is explicit so it shows the intention of the user. So we can blame the user to destroy the coroutine frame incorrectly in case of use-after-free happens. But we can't do so with stack unwinding. So after this patch, we won't think the exceptional terminator don't leak the coroutine handle unconditionally. Instead, we think the exceptional terminator will leak the coroutine handle too if the coroutine is leaked somewhere along the search path. Concretely for C++, we can think the exceptional terminator is not special any more. Maybe this may cause some performance regressions. But I've tested the motivating example (std::generator). And on the other side, the coroutine elision is a middle end opitmization and not a language feature. So we don't think we should blame such regressions especially we are correcting the miscompilations.
Diffstat (limited to 'flang/lib/Frontend/CompilerInvocation.cpp')
0 files changed, 0 insertions, 0 deletions