On Dec 11 19:45, Jim Wilson wrote:
Similar to the previous powf patch, we have a double 0.0/0.0 divide being
used to generate a NaN, which on a single float only target pulls in divdf3.
wf_log.c calls nan instead. I fixed powf to do the same.
With this patch, and a small testcase, I see
gamma02:2368$ ls -lt a.out*
-rwxrwxr-x 1 jimw jimw 32912 Dec 11 19:35 a.out
-rwxrwxr-x 1 jimw jimw 46992 Dec 11 18:54 a.out.unpatched
gamma02:2369$
So the patched code is about 70% of the size of the unpatched code.
This was tested with the testcase included below, and a newlib make check.
Jim
newlib/
* libm/math/wf_pow.c (powf): Call nan instead of double 0.0/0.0.
---
newlib/libm/math/wf_pow.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/newlib/libm/math/wf_pow.c b/newlib/libm/math/wf_pow.c
index be453558b..1e0447173 100644
--- a/newlib/libm/math/wf_pow.c
+++ b/newlib/libm/math/wf_pow.c
@@ -108,7 +108,7 @@
if (_LIB_VERSION == _SVID_)
exc.retval = 0.0;
else
- exc.retval = 0.0/0.0; /* X/Open allow NaN */
+ exc.retval = nan(""); /* X/Open allow NaN */
As far as I can see, that still pulls in an unnecessary function call,
nan().
What about using NAN? That's basically __builtin_nanf("") and usually
resolves without function call on any platform.