Re: alpha return address patch

[Jim Wilson <wilson at cygnus dot com>]

	This may be true for the exception code, but it is not necessarily
	true for any use of the function by user code.  Is it not, IMO, a
	good idea to impose this restriction, since that it is pointlessly 
	arbitrary -- the information is there to be had, we're just being
	lazy about getting it.  It is completely inexcusable to just silently
	generate bad code when it happens, as the MIPS port does.

On the other hand, it can be a bad idea for users to try to use builtin
functions that were designed for gcc's internal use.  This just generates
random bug reports that take time to fix that would be better spent
on real problems.  The sad fact is that if you allow users to use internal
builtin functions, they will use them in unpredicatable ways, and then demand
that you make them work the way they expect them to work.  This can be a
hassle.

This also hinders future improvements to gcc.  Suppose we discover some way
to make exception handling more efficient that requires changes to
builtin_return_address.  If there is user code that relies on the current
semantics of builtin_return_address, then we are stuck unless we create a
new builtin function.  This is an unnecessary inconvenience.  We should not
allow user code to interfer with gcc internal design issues.

There are also other problems with builtin_return_address.  For instance,
what should the value actually be?  Is it the return address saved by the
call instruction, or is the address that the function will return to?  On
some machines these are different.  For instance, in the 32 bit sparc ABI,
functions return to $ra+8 normally, and to $ra+12 if the return value is
a structure.  builtin_return_address happens to return $ra, and the exception
handling code knows this.  However, if we allow users to use
builtin_return_address, then it will be the `wrong' value for some of them,
and they will report it as a bug.

The only elegant solution is to adopt the convention that internal builtin_*
functions are undefined when used in user code.  Of course, some builtin
functions are OK for user code.  It is only the ones that depend on gcc
internals that I am concerned about.  We should discourage users from
using them.

Jim