From: Nikodemus Siivola <nikodemus@ra...>  20080113 13:47:02

On 1/13/08, Nikodemus Siivola <nikodemus@...> wrote: > ...which makes life a lot easier. Up to a point, at least. :) Here's the underlying problem: On x86 we perform singlefloat + integer normally using doubleprecision, and then coerce the result back to singlefloat. (The FILD instruction always gives us a doublefloat, and unless we do MOVEFROMSINGLE it remains one. Or so it seems to me, and that would also explain the observed behaviour below.) During IR1 we derive the types for both (+ <single> <integer>) ; uses doubleprecision (+ <single> (FLOAT <integer> <single>)) ; uses singleprecision and get a mismatch for a number of unlucky arguments. The use of doubleprecision in the first case appears to be an (un)happy accident  interval arithmetic gives us the doubleprecision result because that's what the backend does. (+ 8172.0 (coerce 95195347 'singlefloat)) ; => 9.518717e7 (+ 8172.0 95195347) ; => 9.5187176e7 (coerce (+ 8172.0 (coerce 95195347 'doublefloat)) 'singlefloat) ; => 9.5187176e7 I don't have an immediate idea how to fix this, except by making sure %SINGLEFLOAT always creates singlefloats, even if the result is consumed immediately. ...but I'm not sure if that's the right thing, or if the right thing would be to deal with this in the IR1 (somehow). Cheers,  Nikodemus 