library builtins and exceptions

Ben, Chad, et al.,

Looking at the list of libm library builtins in Builtins.def, only cimag and creal are marked with 'n' (nothrow). Is this because the other functions can issue floating-point exceptions? It seems that this prevents the functions from being marked as 'nounwind' in the IR (but only in C++ mode). A couple of questions:

1. Is this really necessary? First, if it is necessary, then it seems wrong for C (because we only don't emit nounwind for C++ codes). Also, if the function is already marked as 'readonly', is that not sufficient? A 'readonly' function can still trap (by dereferencing a null pointer, for example).

2. If I'm right about the 'n' -> floating-point exception relationship, then it should be turned off when -fno-trapping-math is provided (but its not). If the answer to question 1 is, 'yes, it is needed", then is the best way to implement this to do the same thing here as is done for the 'e' (const when -fmath-errno=0) flag?

Thanks in advance,
Hal

Floating point exceptions do not unwind the stack, so marking all floating point functions as nounwind should be safe. This was probably just an oversight, note that "const" implies nounwind so most of the functions were getting the attribute already.

- Ben

> Ben, Chad, et al.,
>
> Looking at the list of libm library builtins in Builtins.def, only
> cimag and creal are marked with 'n' (nothrow). Is this because the
> other functions can issue floating-point exceptions? It seems that
> this prevents the functions from being marked as 'nounwind' in the
> IR (but only in C++ mode). A couple of questions:
>
> 1. Is this really necessary? First, if it is necessary, then it
> seems wrong for C (because we only don't emit nounwind for C++
> codes). Also, if the function is already marked as 'readonly', is
> that not sufficient? A 'readonly' function can still trap (by
> dereferencing a null pointer, for example).
>
> 2. If I'm right about the 'n' -> floating-point exception
> relationship, then it should be turned off when -fno-trapping-math
> is provided (but its not). If the answer to question 1 is, 'yes,
> it is needed", then is the best way to implement this to do the
> same thing here as is done for the 'e' (const when -fmath-errno=0)
> flag?

Floating point exceptions do not unwind the stack, so marking all
floating point functions as nounwind should be safe. This was
probably just an oversight, note that "const" implies nounwind so
most of the functions were getting the attribute already.

Thanks! I'll post a patch for review soon that should clean this up.

-Hal