Re: forcing tail/sibling call optimization

[ebiederm at xmission dot com (Eric W. Biederman)]

Bernd Schmidt <bernds@redhat.com> writes:

> Even an explicit statement doesn't help you because even if it doesn't warn
> when compiling for one machine, it might still warn on another machine, or
> with a different version of the compiler.

It shouldn't warn. It should fail a tail call cannot be implemented correctly.
That is the whole point of the extension.

Allowing __tailcall to fail for now seems a reasonable compromise
so it is not required on every platform immediately.  Better still
would be to require it on every platform.

OTOH it is fine to let things like trying to tail call a varargs function
to be illegal.

> IMHO we shouldn't encourage users to rely on gcc being able to optimize
> tail calls.  It's a nice optimization, but if a program relies on it for
> correctness, that program is broken.

There are certain classes of programs that run just fine in C except
they occasionally get unnecessary stack overflows.    A guarantee
that they would not get a stack overflow enables these classes of programs
to be written in C.

Just as inline allows macros to be removed.  
return __tailcall func(); allows state machines to be implemented
with each state a separate function instead of the classic,
state = FOO;
switch (state) {
case A:
case B:
case FOO:
}

There are other examples as well. 

Eric