[Mono-bugs] [Bug 54467][Wis] Changed - Incorrect values when subtracting doubles

bugzilla-daemon@bugzilla.ximian.com bugzilla-daemon@bugzilla.ximian.com
Thu, 20 May 2004 05:08:28 -0400 (EDT)

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by massi@ximian.com.


--- shadow/54467	2004-05-20 04:55:06.000000000 -0400
+++ shadow/54467.tmp.17066	2004-05-20 05:08:28.000000000 -0400
@@ -115,6 +115,35 @@
 ------- Additional Comments From massi@ximian.com  2004-05-20 04:55 -------
 Created an attachment (id=7774)
 Preliminary patch (I'd need comments on the two solutions...)
+------- Additional Comments From massi@ximian.com  2004-05-20 05:08 -------
+The previous attachment is a preliminary fix.
+Actually, two different implementation strategies are tried,
+one for sin and cos and the other for tan and atan.
+The difference is that in tan and atan it was clear that at
+least one fp register was already available, so it is possible
+to use the fast fldz-fadd sequence without risking anything.
+For sin and cos, on the other hand, this is not true, so I
+build a ((double)0) on the memory stack and use it (instead
+of issuing a fldz).
+I was also thinking of not implementing the fix in the switch
+inside mono_arch_output_basic_block, but having the "Sin" and
+"Cos" methods generating more that one IR opcode, so that the
+code that takes care of spills would kick in automatically.
+Of course this should happen only on x86...
+The reason why I did not do it is that I am not sure about the
+possibility that optimizations remove that code (adding 0.0
+should look a useless thing to the optimizer).
+Comments appreciated...
+By the way, the "test_0_sqrt_precision_and_spill" test still
+fails, but this is not exactly related to this bug... I am
+still investigating it.