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 also possible there is a genuine error. Any ideas? I'd be curious to see the generated asm. On May 29, 2013, at 3:28 PM, Sven Hartrumpf <hartru...@gmx.net> wrote: > Hi Peter. > > Wed, 29 May 2013 19:06:26 +0200, Peter.Bex wrote: >> This patch should fix it, but it does in a roundabout way: converting >> the number to a string causes it to lose precision because of the default >> value of (flonum-print-precision). It's more explicit to check whether >> the two values lie within an epsilon of eachother, like the test egg does. > > I hoped that there will be a better patch. Thanks, Peter. > >> Could you try whether "make check" on a -O3-compiled CHICKEN succeeds >> with the attached patch? > > It does! > (Also for -O2.) > > Ciao > Sven > > _______________________________________________ > Chicken-hackers mailing list > chicken-hack...@nongnu.org > https://lists.nongnu.org/mailman/listinfo/chicken-hackers _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users