me: i wish we could have tail calls in c
gcc: we have tail calls at home
the tail calls:

https://godbolt.org/z/GT5PvnxP9

a kind person shares this powerful incantation: `if (1) [[gnu::musttail]]` https://godbolt.org/z/f8fzf9b5M
Compiler Explorer - C (x86-64 gcc 15.2)

int f(void); static int g(void) { return f(); return 11; } static int h(void) { if (1) [[gnu::musttail]] return f(); return 42; }

lol gcc's tail call implementation is extraordinarily squirrely, it happily inlines functions that do tail calls but then dies because it fails to turn the inlined tail calls into regular calls. (clang fails in different ways :P)
"cannot tail-call: other reasons" this energy is sending meeeeee, the compiler has determined that it is friday

@wingo I had patches to improve the error message here. I cant remember what happened to them though.
Oh now I remember it was stage4 last year and I forgot to submit them during stage 1 because I was busy trying to get other tail calls working. And other optimizations happening .

Let me see if I can dig them up again and submit them for gcc 17 when stage1 opens up again.

@wingo also we fixed a lot of musttail issues during stage4 for gcc 15.

Please file a bug since it does not get tracked otherwise. Also note which target you are doing it on. Since tail calls are target dependent.

Gcc tries it's hardest at -O0 for musttail but -O0 really falls the most too.

@pinskia hey thanks for the note! will do my best to file. thank you for musttail!!

@wingo

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115979
is recording at least one example of musttail error message being "other reasons". I have not looked if this is your case though.

115979 – Implicitly generated C++ calls stop musttail search early

@wingo Thanks again for the bug reports.

The fix for the musttail on the second return (first reported here in the original thread) should be easy to fix; it looks like an oversight really. There has been more testing with the C++ front-end than the C front-end when it comes to musttail due to the usage in open source has been with C++ code. (GCC's C and C++ front-end share some code but a lot of is not; this is different from clang where the parsers are even shared).

The fix for the inlining case is harder but I know what is causing it at least. I have some ideas on fixing it in a reasonable and quick fashion; as I mentioned in the bug report -fno-tree-sra is a decent workaround for now.

Note my name is different between GCC bugzilla and here.

@pinskia many thanks!! also congrats on the new name 👏