[PATCH] D39611: [CodeGen] make cbrt and fma constant (never set errno); document complex calls as always constant

[Hal Finkel via Phabricator via cfe-commits]

hfinkel added a comment.

In https://reviews.llvm.org/D39611#915799, @efriedma wrote:

> > In general, because all of these functions are well defined over the entire complex domain, they don't have errors. The "no errors defined" is likely correct.
>
> One, it is not true that all these functions are well-defined over the entire complex domain.  For example, according to the C standard `catanh(1)` raises a divide-by-zero error.


True. That's why I said that the statement was true in general. There are a few exceptions.

> Two, even for the functions which are defined over the entire complex domain, the result can still overflow and/or underflow, and therefore they could set errno to ERANGE.  cabs() can overflow, cexp() can overflow, etc.
> 
> Three, even if we only care about the behavior of the current version of glibc, cabs() actually does modify errno. (Try `cabs(1.7e308+I*1.7e308)`).

As I understand things currently, that's a bug:

In the C specification, 7.12 specifies the requirements for functions in math.h. For those functions, 7.12.1 (Treatment of error conditions) says that overflows do set ERANGE, and that it's implementation defined if the same is true for underflows. That's true for functions in math.h in general. 7.3 specifies the requirements for functions in complex.h. Here, 7.3.2 says, "An implementation may set errno but is not required to." That, as I understand it, applies to all functions in complex.h (unless otherwise noted, I presume). However, because setting errno is not required by C for functions in complex.h, when POSIX says "No errors are defined." that constrains the choice (POSIX is constraining the implementation choice allowed by C; this is not a contraction with the C specification). As a result, under POSIX, the functions in complex.h don't set errno (some, as you've noted, may raise FP exceptions, but that's another matter).

Regarding glibc-specific behavior, I do want us to be careful only to model this behavior when the target triple has -gnu. Otherwise, we should stick to the standard behavior.


https://reviews.llvm.org/D39611