Andy Wingome: i wish we could have tail calls in c
gcc: we have tail calls at home
the tail calls:
a kind person shares this powerful incantation: `if (1) [[gnu::musttail]]` https://godbolt.org/z/f8fzf9b5M
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)
Kauê HB"cannot tail-call: other reasons" this energy is sending meeeeee, the compiler has determined that it is friday
void friend@wingo I see why you liked the
if (1)… Good luck with the tail calls.@void_friend fwiw, i got it to work if i __attribute__((noinline)) the functions that make tail calls 😅
@wingo Why doesn't enabling the tail-call optimization for the entire compilation unit work for you? You're already targeting a GCC-like compiler anyway, surely you're compiling the C file yourself or can tell the person who will compile it to use
-foptimize-sibling-calls (I think the option is)?@wingo Also, I wonder if you could implement tail calls in standard C from
longjmp (pls do not implement tail calls from longjmp)@void_friend in this case i am compiling from wasm which has guaranteed tail calls (in addition to normal calls); optimizations are great obviously but the sibling calls thing is both not guaranteed and doesn’t work at -O0
@wingo A transformation that is always a gain (although not for debugging perhaps, who knows what C developers expect to see in
gdb), to the point that it's guaranteed with no way to disable it in many other programming languages, is not guaranteed when the option that turns it on is explicitly used? GCC keeps surprising me…GCC developers (a long time ago, do not hold them to it, actually it was possibly only RMS who said this): “we come from LISP and we will add many LISP-inspired extensions to standard C”
Also GCC developers: …
Alex Celeste, Princess Consort of Burnout@wingo per TS25007 "unspecified other reasons" is conforming
Emil J@wingo musttail is the weirdest feature, since unlike literally everything else, if they're supposed to be helpful and not just error out on almost everything, it requires error explanations spanning almost all of the compilation, through all the opt sequencing. If they're resolved in the compiler, they're crazy pessimistic. I'll never use [[musttail]] after getting intimate with them when working on a downstream llvm backend, there's no way to make it make sense IMO. Gcc is reasonable to shrug
✧✦Catherine✦✧@wingo i was gonna say "being overly strict by matching strictly on syntax is fine, you wouldn't want changes in the optimizer to determine whether the tail call is generated or not because that makes it really difficult to explain" but i see i was thinking too much of gcc
Andrea (Drea) Tamar Pinski@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!!
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.
@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 👏