https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119376
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |andi-gcc at firstfloor dot org
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
That again depends on the definition of the attribute.
Except for the inlining mentioned here, feels like GCC implements what it
documents, and clang documents something different, in particular
"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.
clang::musttail provides assurances that the tail call can be optimized on all
targets, not just one."
My reading of that is that it isn't just please try hard to tail call this or
error out if it is not possible, but simply a user guarantee that the tail call
is possible if the compiler can actually process it.
So even the
void f(int *);
void g(int *b)
{
int a;
f(&a);
[[clang::musttail]]
return f(b);
}
case could be ok if the user says I know an address of a local variable
escaped, but dereferencing it in the f(b) call will be UB.
And the question is which of the many reasons why a call can't be a tail call
should be in the category user promised it won't happen, don't error, just do
it, and which are still emit an error.
And whether that behavior should happen just for clang::musttail, or
gnu::musttail as well (and if it is different, fuzzy thing is what to do for
__attribute__((musttail)) because there it doesn't differentiate, clang treats
it as their attribute and gcc as gnu).
