This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fixing improper conversion from sin() to sinf() in optimization mode.
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Cong Hou <congh at google dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>, David Li <davidxl at google dot com>
- Date: Fri, 30 Aug 2013 21:51:35 +0000
- Subject: Re: [PATCH] Fixing improper conversion from sin() to sinf() in optimization mode.
- Authentication-results: sourceware.org; auth=none
- References: <CAK=A3=1b=qhx8u8Wz7je=KYUbvOQHyKaWP353ud7D7f8gF56Bw at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1308232046240 dot 12585 at digraph dot polyomino dot org dot uk> <CAK=A3=3=gLhTso3+AF-BmiONPsEpP3dGTFtOAZPbh+oteYPTNA at mail dot gmail dot com>
On Fri, 30 Aug 2013, Cong Hou wrote:
> I have done a simple experiment and found that it may only be safe to do
> this conversion for fabs() and sqrt(). For fabs() it is easy to see the
> safety. For sqrt(), I tried many random floating point values on two
> versions and did not see a difference. Although it cannot prove its safety,
> my proposed patch (shown below) does change the situation.
>
> However, for other functions, my experiment shows it is unsafe to do this
> conversion. Those functions are:
>
> sin, cos, sinh, cosh, asin, acos, asinh, acosh, tan, tanh, atan, atanh,
> log, log10, log1p, log2, logb, cbrt, erf, erfc, exp, exp2, expm1.
I don't see why it would be unsafe for logb - can you give an example
(exact float input value as hex float, and the values you believe logb
should return for float and double).
For sqrt you appear to have ignored my explanation of the necessary and
sufficient condition on the precisions of the respective types. The
conversion is not safe for sqrt if the two types are double and long
double and long double is x86 extended, for example.
--
Joseph S. Myers
joseph@codesourcery.com