Re: x86 JIT and GCC 3.3 don't play well together

[Juergen Boemmels]

Juergen Boemmels <[EMAIL PROTECTED]> writes:

> t/op/number.........NOK 38#     Failed test (t/op/number.t at line 1038)     
> #          got: '12.500000
> # -1.996899
> # '
> #     expected: '12.500000
> # 0.000000
> # '
> # Looks like you failed 1 tests of 38.

I think I found out why this test is failing (randomly):
The null_n op emits in emits the address to a auto variable in
Parrot_null_n_jit. But this frame is destroyed after the emission of
the code. When the code is run it uses a reference to a no longer
existing frame which may contain random data. The value zero has to
outlive the invokation of Parrot_null_n_jit so making zero static
will solve the problem.

Can someone with more jit-experience verify that I'm correct?

bye
boe

Index: jit/i386/core.jit
===================================================================
RCS file: /cvs/public/parrot/jit/i386/core.jit,v
retrieving revision 1.48
diff -u -U7 -r1.48 core.jit
--- jit/i386/core.jit   3 Oct 2003 15:43:49 -0000       1.48
+++ jit/i386/core.jit   13 Oct 2003 19:11:55 -0000
@@ -129,15 +129,15 @@
 }
 
 Parrot_null_s {
     Parrot_null_x s/<_N>/_i/ s/INT_R/STRING_R/ s/<val>/NULL/
 }
 
 Parrot_null_n {
-    FLOATVAL zero = 0;
+    static FLOATVAL zero = 0;
     if (MAP[1]) {
         jit_emit_mov_ri_n(NATIVECODE, MAP[1], &zero);
     }
     else {
         jit_emit_mov_mi_ni(NATIVECODE, &NUM_REG[1], &zero);
     }
 }