https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119376
--- Comment #35 from lucier at math dot purdue.edu --- (In reply to Jakub Jelinek from comment #34) > (In reply to lucier from comment #33) > > It is my understanding that with the set of patches related to this PR, GCC > > 15 with -foptimize-tail-calls will optimize some tail calls that GCC 14 with > > -foptimize-tail-calls will not optimize. This is somewhat independent of > > the fact that GCC 15 has the musttail attribute. > > > > Is my description of the change in behavior between GCC 15 and 14 and > > -foptimize-sibling-calls accurate? > > Yes. Though some changes are done only for calls with musttail attribute (a > few with the intention to extend that to all tail calls in GCC 16, but most > of them only when the attribute is present). Will optimizing some tail calls only with the musttail attribute turn the meaning of -foptimize-sibling-calls into something like "I don't really care if I have a complete backtrace if I hit an error so it's OK with me if you turn some tail calls into jumps"? Up until now, I took that option as a directive to optimize every call it could. That's why I tried to add a warning to report when -foptimize-sibling-calls did *not* actually optimize a tail call. That was rejected, I believe because musttail was coming, which would turn that into an actual error. But if musttail changes the behavior of which tail calls are optimized, it seems again that a warning when -foptimize-sibling-calls fails would be useful.
