https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119718
--- Comment #6 from lucier at math dot purdue.edu --- Thank you for the detailed explanation. What initially got me investigating this is that (a) these tail calls were not optimized by GCC 14 and I got segfaults, so (b) I added musttail and tried it in a month-ago version of GCC 15, which reported that the tail calls weren't optimized but gave something like "other reasons" as the explanation so (c) I updated to yesterday's GCC 15, where they were optimized with musttail, but then (d) with yesterday's GCC 15 I got the segfaults again when I removed the musttail attribute. If musttail is going to change which tail calls are optimized, I really think we need a warning flag that will have GCC give a warning when musttail is not used on a tail call, -foptimize-sibling-calls is given, and a tail call is not optimized for whatever reason. Then someone can look at the reason and decide whether they know what's going on in their code better than what GCC can deduce, and add a musttail to the call. Or not; they may decide, "Oh, look, GCC is right, I should reorganize my code so that this obstruction to tail call optimization is removed." Looking back in my gcc-related mail folder, I see there were discussions about similar issues in 2021 and 2023. I think it would be good for a programmer to know why GCC didn't want to optimize a tail call with -foptimize-sibling-calls before having them just smash a musttail attribute on the call to force the (currently unknown) issue.
