I have updated the patch according to your suggestion, and have
committed the patch as the bootstrapping and make check both get
passed.
Thank you for your patient help on this patch! I learned a lot from it.
thanks,
Cong
On Wed, Oct 23, 2013 at 1:13 PM, Joseph S. Myers
wrote:
> On Mon, 7 Oct
On Mon, 7 Oct 2013, Cong Hou wrote:
> + if (type != newtype)
> +break;
That comparison would wrongly treat as different cases where the types
differ only in one being a typedef, having qualifiers, etc. - or if in
future GCC implemented proposed TS 18661-3, cases where they differ in
e.g.
Ping?
thanks,
Cong
On Mon, Oct 7, 2013 at 10:15 AM, Cong Hou wrote:
> You are right. I am not an expert on numerical analysis, but I tested
> your case and it proves the number 4 conversion is not safe.
>
> Now we have four conversions which are safe once the precision
> requirement is satisfi
You are right. I am not an expert on numerical analysis, but I tested
your case and it proves the number 4 conversion is not safe.
Now we have four conversions which are safe once the precision
requirement is satisfied. I added a condition if (type != newtype) to
remove the unsafe one, as in this
On Fri, 6 Sep 2013, Cong Hou wrote:
> 4: (float) sqrtl ((long double) double_val) -> (float) sqrt (double_val)
I don't believe this case is in fact safe even if precision (long double)
>= precision (double) * 2 + 2 (when your patch would allow it).
The result that precision (double) * 2 + 2 i
Ping...
thanks,
Cong
On Fri, Sep 20, 2013 at 9:49 AM, Cong Hou wrote:
> Any comment or more suggestions on this patch?
>
>
> thanks,
> Cong
>
> On Mon, Sep 9, 2013 at 7:28 PM, Cong Hou wrote:
>> On Mon, Sep 9, 2013 at 6:26 PM, Xinliang David Li wrote:
>>> On Fri, Sep 6, 2013 at 3:24 PM, Cong
Any comment or more suggestions on this patch?
thanks,
Cong
On Mon, Sep 9, 2013 at 7:28 PM, Cong Hou wrote:
> On Mon, Sep 9, 2013 at 6:26 PM, Xinliang David Li wrote:
>> On Fri, Sep 6, 2013 at 3:24 PM, Cong Hou wrote:
>>> First, thank you for your detailed comments again! Then I deeply
>>> ap
On Mon, Sep 9, 2013 at 6:26 PM, Xinliang David Li wrote:
> On Fri, Sep 6, 2013 at 3:24 PM, Cong Hou wrote:
>> First, thank you for your detailed comments again! Then I deeply
>> apologize for not explaining my patch properly and responding to your
>> previous comment. I didn't understand thorough
On Fri, Sep 6, 2013 at 3:24 PM, Cong Hou wrote:
> First, thank you for your detailed comments again! Then I deeply
> apologize for not explaining my patch properly and responding to your
> previous comment. I didn't understand thoroughly the problem before
> submitting the patch.
>
> Previously I
First, thank you for your detailed comments again! Then I deeply
apologize for not explaining my patch properly and responding to your
previous comment. I didn't understand thoroughly the problem before
submitting the patch.
Previously I only considered the following three conversions for sqrt():
On Wed, 4 Sep 2013, Xinliang David Li wrote:
> > This patch submission still fails to pay attention to various of my
> > comments.
> >
>
> If you can provide inlined comments in the patch, that will be more
> useful and productive.
I have explained things several times in this thread already. I
Updated patch according to your comment (tabs are not pasted here).
Cong
Index: gcc/convert.c
===
--- gcc/convert.c (revision 201891)
+++ gcc/convert.c (working copy)
@@ -135,16 +135,40 @@ convert_to_real (tree type, tree expr)
C
On Wed, 4 Sep 2013, Cong Hou wrote:
> I have made a new patch according to your comments. I found several
> references saying that the precision 2p+2 is OK for the sqrt
> conversion (one here:
> http://www.cs.berkeley.edu/~fateman/generic/algorithms.pdf). The new
> patch is pasted as below.
This
I have made a new patch according to your comments. I found several
references saying that the precision 2p+2 is OK for the sqrt
conversion (one here:
http://www.cs.berkeley.edu/~fateman/generic/algorithms.pdf). The new
patch is pasted as below.
Thank you for all the suggestions, Joseph!
Cong
On Wed, Sep 4, 2013 at 1:59 PM, Joseph S. Myers wrote:
> On Wed, 4 Sep 2013, Cong Hou wrote:
>
>> I have made a new patch according to your comments. I found several
>> references saying that the precision 2p+2 is OK for the sqrt
>> conversion (one here:
>> http://www.cs.berkeley.edu/~fateman/gene
On Wed, Sep 4, 2013 at 1:53 PM, Cong Hou wrote:
> I have made a new patch according to your comments. I found several
> references saying that the precision 2p+2 is OK for the sqrt
> conversion (one here:
> http://www.cs.berkeley.edu/~fateman/generic/algorithms.pdf). The new
> patch is pasted as b
On 4 September 2013 00:17:00 Cong Hou wrote:
Could you please tell me how to check the precision of long double in
GCC on different platforms?
I did not follow your discussion but..
http://uclibc.org/~aldot/precision_check.f
Or something along those lines in your favourite language.
HTH..
Th
On Tue, 3 Sep 2013, Cong Hou wrote:
> Could you please tell me how to check the precision of long double in
> GCC on different platforms?
REAL_MODE_FORMAT (TYPE_MODE (long_double_type_node))->p
(but you should be referring to the relevant types - "type", the type
being converted to, "itype", th
>From Joseph:
"The
conversion is not safe for sqrt if the two types are double and long
double and long double is x86 extended, for example."
This is not reflected in the patch.
David
On Tue, Sep 3, 2013 at 2:27 PM, Joseph S. Myers wrote:
> On Tue, 3 Sep 2013, Cong Hou wrote:
>
>> + CASE_MAT
On Tue, 3 Sep 2013, Cong Hou wrote:
> + CASE_MATHFN (SQRT)
> +/* sqrtl(double) cannot be safely converted to sqrt(double). */
> +if (fcode == BUILT_IN_SQRTL &&
> +(TYPE_MODE (type) == TYPE_MODE (double_type_node)) &&
> +!flag_unsafe_math_opt
Could you please tell me how to check the precision of long double in
GCC on different platforms?
Thank you!
Cong
On Tue, Sep 3, 2013 at 2:43 PM, Joseph S. Myers wrote:
> On Tue, 3 Sep 2013, Xinliang David Li wrote:
>
>> >From Joseph:
>>
>> "The
>> conversion is not safe for sqrt if the two ty
On Tue, 3 Sep 2013, Xinliang David Li wrote:
> >From Joseph:
>
> "The
> conversion is not safe for sqrt if the two types are double and long
> double and long double is x86 extended, for example."
>
> This is not reflected in the patch.
No, the problem is that it tries to reflect it but hardcod
I have fixed my test code and replaced those aliasing violations with
unions. Now the test result shows logb() is safe for the conversions.
The conclusion is, logb() and fabs() are always safe for the
converion, and sqrt() is unsafe for the conversion from sqrtl(double)
to sqrt(double). Other math
On Sat, 31 Aug 2013, Cong Hou wrote:
> > 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).
> >
>
> Please try the following code (you will get different results
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.
On Tue, 20 Aug 2013, Cong Hou wrote:
> When a sin() (cos(), log(), etc.) function is called on a value of
> float type and the returned double value is converted to another value
> of float type, GCC converts this function call into a float version
> (sinf()) in the optimization mode. This avoids
When a sin() (cos(), log(), etc.) function is called on a value of
float type and the returned double value is converted to another value
of float type, GCC converts this function call into a float version
(sinf()) in the optimization mode. This avoids two type conversions
and the float version fun
27 matches
Mail list logo
