How inlined are inlined functions?

[Joe Buck]

Mark Mitchell <mark@codesourcery.com> wrote:

> > (In fact, we can now inline some functions [...] that contain
> > setjmp.)

Alexandre Oliva writes:

> Isn't this dangerous?  Assume I have worked hard to volatilize just
> the minimal set of variables of a function to make sure it's
> setjmp()-safe.  But then, it happens to be inlined (assume -O3, i.e.,
> the function is not explicitly declared inline), but the caller
> variables are not properly volatilized.  Wouldn't it break?

The issue is that longjmp is allowed to trash all of the automatic
variables in the caller to setjmp when a "longjmp return" occurs, but
we can't let it trash automatics in the parent function, unless those
variables cannot be reached by any control path following the longjmp.

So if the implementation ignores the issue, then yes, it seems it would
break; however, there are cases where no automatic variables are used
after a longjmp return.  Example:

jmp_buf	setjmp_buf;

// foo might call longjmp through setjmp_buf.

bool foo();

// return true if foo succeeds, false if it fails or does longjmp

inline bool try_foo()
{
	return setjmp(setjmp_buf) == 0 && foo();
}

bool top_func()
{
	int a;
	double b;
	if (!try_foo()) return false;
	... more code here ...
}

Here, inlining try_foo would trash a and b, which in some circumstances
is not allowed, but here, who cares?  They aren't even initialized.

> Shouldn't
> such functions only be inlined when they're explicitly declared
> inline?

That doesn't change the issue: the automatic variables of the caller
still need to be preserved, otherwise we don't have a correct ISO C++
compiler.