Re: Functions that always return

[Mike Stump <mrs at windriver dot com>]

> From: Michael Hayes <mhayes@redhat.com>
> Date: Sat, 28 Oct 2000 15:15:27 +1300 (NZDT)
> To: gcc@gcc.gnu.org

> Is there a mechanism where we tell if a CALL_INSN will always return?

> I had always assumed that a libcall would always return but looking
> in libgcc2.c, I see that udivmoddi4 may generate a divide by zero
> exception.  This puzzles me since I see that a libcall to udivmoddi4
> has a REG_EH_REGION note with a value of -1 which I thought
> indicated that the call could not throw an exception?

> Could someone please clarify the situation.

First, exception != exception.  Usually I don't see one person use the
word twice in one paragraph using both definitions.  One causes a
signal to be sent to the process and the other one is a C++ exception.

You can never know if anything returns.  Almost all functions are
permitted to longjmp, call exit or loop infinitely, because of this,
you can't know that they return.

It is beyond the Standards for the libcall in question to throw a C++
exception.  It isn't that we can't do it, it is that we haven't
decided yet to support that.  So, we can say that REG_EH_REGION should
have a -1 in it, because we know it can't throw.  Bear in mind
-fasync-exceptions should change the meaning of the RTL to indicate it
can throw.  That flag indicates that anything can throw, it is
precisely so that throwing from signal handlers have more of a chance
of not failing.

If someone wants to support throwing a C++ exceptions on C signal type
exceptions in other than the presence of -fasync-exceptions, then one
could do that.  I don't think anyone has been down that road yet.

As a group, we need to stop using the phrase expcetion to mean a
signaling event and only use the word to mean things related to the
file except.c.  I'd propose raise a signal, fault or interrupt.