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

[bugzilla-daemon@bugzilla.ximian.com]

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.

http://bugzilla.ximian.com/show_bug.cgi?id=54467

--- 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.
+