From: <no...@so...> - 2002-09-26 20:46:44
|
Bugs item #614971, was opened at 2002-09-27 01:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=614971&group_id=2435 Category: mingw runtime Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Van Holder (zastai) >Assigned to: Danny Smith (dannysmith) Summary: HUGE math bug when crosscompiling Initial Comment: I'm crosscompiling to mingw32 from a Linux host, using stock gcc 3.2, and the current mingw32 packages (w32api 2.0, and runtime 2.2). There's a HUGE bug in the math library, it seems: the following simple program: #include <math.h> int main(void) { int i = 0; for (i = 0; i < 10; ++i) printf ("10**%d = %d\n", i, (int) pow ((double)10, (double)i)); } produces the following: 10**0 = 1 10**1 = 10 10**2 = 99 10**3 = 1000 10**4 = 9999 10**5 = 100000 10**6 = 1000000 10**7 = 9999999 10**8 = 99999999 10**9 = 999999999 This happens both with and without -lm. The powf and powl functions in libmingwex (why not in libm?) do work as expected. Is this a bug in the runtime (seems likely), or are there some patches that need to be applied to gcc 3.2 first? ---------------------------------------------------------------------- >Comment By: Danny Smith (dannysmith) Date: 2002-09-27 08:46 Message: Logged In: YES user_id=11494 Thanks for the report and testcase. Hmm, it seems that the mscvcrt version of pow is tweaked for 53-bit precison. Maybe it uses a look-up table for logs of small integral values. (Maybe it uses Earnie's slide-rule) If I do this : gcc main.c /mingw/lib/crt_fp8.o to force 53-bit, the results are correct. I can provide a 64-bit version of pow(double,double) in libmingwex.a for next release. Danny ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=614971&group_id=2435 |