http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46080
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46080
Richard Guenther changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46080
--- Comment #12 from Jakub Jelinek 2010-10-26
13:41:10 UTC ---
Well, the setting of errno by calling another function has similar effects like
calling any other function in between, if you do
float a = sqrtf (x);
foo ();
float b = sqrtf (x)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46080
--- Comment #11 from Paul Zimmermann 2010-10-22
06:56:20 UTC ---
(In reply to comment #10)
> You can use -fno-errno-math if you don't want errno to be set, then there will
> be no calls to sqrtf and all 3 calls should at least when optimizing eva
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46080
--- Comment #10 from Jakub Jelinek 2010-10-21
20:55:58 UTC ---
fsqrt insn is always used, and if the result is NaN, it calls library sqrtf
function so that errno is set correctly. The (conditional) call causes (some
of) the values to be forced i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46080
--- Comment #9 from Paul Zimmermann 2010-10-21
19:26:11 UTC ---
(In reply to comment #8)
> You really should use hex float to see the diferences. I bet it is just the
> final digit of the hex float that is different and only by one. This is
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46080
--- Comment #8 from Andrew Pinski 2010-10-20
23:49:18 UTC ---
%.60f
You really should use hex float to see the diferences. I bet it is just the
final digit of the hex float that is different and only by one. This is
actually ok IIRC.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46080
--- Comment #7 from Vincent Lefèvre 2010-10-20
23:43:33 UTC ---
But there's something strange in the generated code: sometimes the fsqrt
instruction is used, sometimes "call sqrtf" is used (for the same sqrtf() call
in the C source). This is not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46080
--- Comment #6 from Jakub Jelinek 2010-10-20
10:46:14 UTC ---
That depends on the register allocation, whether the result of fsqrt needs to
be flushed into memory or can stay in the i387 register stack. In the former
case it gets rounded from lo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46080
--- Comment #5 from Paul Zimmermann 2010-10-20
09:54:01 UTC ---
(In reply to comment #3)
> You should use -ffloat-store to remove excess precision.
the main issue is not the excess of precision, but the fact that identical
calls
to printf with i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46080
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46080
--- Comment #3 from Uros Bizjak 2010-10-20 08:28:57
UTC ---
(In reply to comment #2)
> Created attachment 22089 [details]
> sh script to test sqrtf
>
> Similar problems can also be found with:
>
> printf ("%.60f\n%.60f\n%.60f\n", sqrtf(x), sq
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46080
--- Comment #2 from Vincent Lefèvre 2010-10-20
01:51:56 UTC ---
Created attachment 22089
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22089
sh script to test sqrtf
Similar problems can also be found with:
printf ("%.60f\n%.60f\n%.60f\n
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46080
Richard Guenther changed:
What|Removed |Added
Target||i?86-*-*
Status|UNCONFIRME
14 matches
Mail list logo
