On Tue, 1 Apr 2025, Jakub Jelinek wrote: > 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.
OK. I wonder if we can amend the documentation to suggest to end lifetime of variables explicitly by proper scoping? Thanks, Richard.
