On Tue, Mar 25, 2025 at 07:43:28PM +0300, Alexander Monakov wrote:
> FWIW I think Clang made a mistake in bending semantics in a way that is
> clearly
> misaligned with the general design of C and C++, where a language-native, so
> to
> speak, solution was available: introduce a scope for the local variables to
> indicate that they cannot escape to the intended tailcall:
>
> void foo(int v)
> {
> {
> int a;
> capture(&a);
> }
> tailcall(v); // this cannot refer to 'a', even though it escaped earlier
> }
>
> I think this would be easily teachable to users who need [[tailcall]].
>
> I wonder if Clang folks would be open to a dialogue about undoing this
> misdesign. I'd rather not see it propagated into GCC.
I'm not excited about it either, but they had introduced the attribute with
this behavior already 3.5 years ago and it is used in the wild, we should
have complained before that did that :(.
And having significantly different behavior for attribute with the same name
(especially [[clang::musttail]], but also the __attribute__((musttail)) form
which is supposed to be gnu::musttail but they handle it like
clang::musttail) would be confusing to users as well.
For the
void bar (int *);
void
foo (int *x)
{
int a;
[[clang::musttail]] return bar (&a);
}
case they now (newly) warn by default and the posted patch warns by default
too, for the other case I've put the warning into -Wextra but am open to
move it to -Wall.
Adding compound statement with the locals is definitely what users can then
do to silence that warning; unfortunately one can't do that with function
arguments if their addresses escape.
Jakub
