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

[Sanjay Patel via Phabricator via cfe-commits]

spatel added a comment.

In https://reviews.llvm.org/D39611#915812, @hfinkel wrote:

> 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.


I'll split 'complex' off into its own patch then. We'll need a new attribute code for those functions. Something like:
//  E -> const when -fmath-errno=0 or in a GNU (or a POSIX-compliant?) environment

I think we can detect GNU-ness with:
Context.getTargetInfo().getTriple().isGNUEnvironment()

But is that correct? If this is actually a POSIX-compliance-based constraint of the choice to not set errno, then GNU is not wide enough to cover other platforms like macOS or AIX that are (mostly?) POSIX-compliant. Also, does GNU guarantee POSIX-compliance?


https://reviews.llvm.org/D39611