Hi! On Tue, Mar 25, 2025 at 08:34:10AM +0100, Jakub Jelinek wrote: > As discussed here and in bugzilla, [[clang::musttail]] attribute in clang > not just strongly asks for tail call or error, but changes behavior. > To quote: > https://clang.llvm.org/docs/AttributeReference.html#musttail > "The lifetimes of all local variables and function parameters end immediately > before the call to the function. This means that it is undefined behaviour > to pass a pointer or reference to a local variable to the called function, > which is not the case without the attribute. Clang will emit a warning in > common cases where this happens." > > The GCC behavior was just to error if we can't prove the musttail callee > could not have dereferenced escaped pointers to local vars or parameters > of the caller. That is still the case for variables with non-trivial > destruction (even in clang), like vars with C++ non-trivial destructors or > variables with cleanup attribute. > > The following patch changes the behavior to match that of clang, for all of > [[clang::musttail]], [[gnu::musttail]] and __attribute__((musttail)). > > clang 20 actually added warning for some cases of it in > https://github.com/llvm/llvm-project/pull/109255 > but it is under -Wreturn-stack-address warning. > > Now, gcc doesn't have that warning, but -Wreturn-local-addr instead, and > IMHO it is better to have this under new warnings, because this isn't about > returning local address, but about passing it to a musttail call, or maybe > escaping to a musttail call. And perhaps users will appreciate they can > control it separately as well. > > The patch introduces 2 new warnings. > -Wmusttail-local-addr > which is turn on by default and warns for the always dumb cases of passing > an address of a local variable or parameter to musttail call's argument. > And then > -Wmaybe-musttail-local-addr > which is only diagnosed if -Wmusttail-local-addr was not diagnosed and > diagnoses at most one (so that we don't emit 100s of warnings for one call > if 100s of vars can escape) case where an address of a local var could have > escaped to the musttail call. This is less severe, the code doesn't have > to be obviously wrong, so the warning is only enabled in -Wextra. > > And I've adjusted also the documentation for this change and addition of > new warnings.
I'd like to ping the https://gcc.gnu.org/pipermail/gcc-patches/2025-March/679182.html patch. I know it is quite controversial and if clang wouldn't be the first to implement this I'd certainly not go that way; I am willing to change the warning option names or move the maybe one from -Wextra to -Wall if there is agreement on that. Unfortunately there seems to be quite a lot of code in the wild that uses this attribute already and without this patch GCC 15 will simply not be able to compile that (whether it is firefox (skia etc.), protobuf, ...). The only other option is IMHO to drop the musttail attribute support for GCC 15 or name it differently with different semantics. But not sure projects in the wild will like to annotate their calls with two different musttail like attributes if they satisfy behavior of both. Jakub
