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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
