On Wed, May 29, 2013 at 03:41:30PM -0500, Jim Ursetto wrote: > I am curious why this happens though. The only thing I could think of was > the number is being constant folded in one case or being computed in one case > via a hardware intrinsic instead of libm in the other, but the generated C > code looks identical in both cases. Perhaps some previous register state > makes the values be off slightly, but to a degree gcc deems acceptable with > -O2?
It's -O2 the gcc flag, not the CHICKEN flag. > It's also possible there is a genuine error. Any ideas? I'd be curious to > see the generated asm. It must be due to gcc spotting the call to sin() with a constant, then replacing it with a precalculated constant in the generated machine code. The fpsin expands to a C inline call to sin(), whereas the sin() call expands to a call to C_a_i_flonum_sin, which is not inlineable so it has to issue a proper function call. This then goes through libm, which is potentially different from the sin() implementation in gcc. I don't have the time to verify all of this, but I've seen things like this before, and it can be a load of fun trying to debug this shit: http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=46388 Cheers, Peter -- http://www.more-magic.net _______________________________________________ Chicken-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-users
