<div dir="ltr">On Fri, Sep 6, 2013 at 8:27 AM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Ben, Chad, et al.,<br>
<br>
The attached patch cleans up the LIBBUILTIN libm function definitions, and improves the way in which -ftrapping-math is handled in a complementary way. Specifically, this patch:<br>
<br>
 1. The libm LIBBUILTIN definitions are synchronized with the __builtin_* definitions for libm functions. We currently have __builtin_* definitions for many more functions than those for which we have LIBBUILTIN definitions. This unnecessarily pessimizes code generation around many of the remaining libm functions.<br>

<br>
 2. Many of these functions can be marked as readnone so long as we can neglect floating point exceptions. I've added a new specifier 'T', which like 'e' for errno, marks the builtin as const so long as trapping math is disabled. I've added a TrappingMath lang option to track this.<br>

<br>
 3. Disables -ftrapping-math by default. This is currently enabled by default (following gcc), but this is silly. No system of which I'm aware actually traps on floating-point exceptions by default (some system-specific mechanism is necessary in order to enable SIGFPE generation). In addition, in Clang, we currently don't support fenv access. As a result, we can turn this off by default (and enable better code generation around the functions for which we have LIBBUILTIN definitions).<br>

<br>
 4. Updates the CodeGen/libcall-declarations.c test case.<br>
<br>
As a side effect, the existing libm LIBBUILTIN definitions that were missing the 'n' (nothrow) specifier now have it.<br></blockquote><div><br></div><div>For clarity, please split the patch into four separate patches: reformatting, adding missing 'n' specifiers, the trapping-math-related changes, and adding new LIBBUILTIN definitions (preferably in that order).  As it is, the Builtins.def changes are completely unreviewable.</div>
<div><br></div><div>Your changes could be substantially simplified if we don't allow enabling -ftrapping-math; as you've noted, we don't honor it anyway.  What do you think?</div><div><br></div><div>-Eli</div>
</div></div></div>