From: <sis...@op...> - 2013-12-12 08:42:23
|
-----Original Message----- From: Jared Maddox >> Absolutely correct - if the problem is with MS, then file a report there. >> But the thing I don't understand is how it can be a problem with MS yet >> not >> affect the mingw64 compilers that I have running on this same machine. > > The gcc that you're having problems with is targeting 32-bit, and the > one that's fine is targeting 64-bit, right? I was thinking that the 32-bit mingw64 compiler (which is fine) is targeting 32-bit. If not then that probably explains it. > You said that one or another of the Microsoft compilers was producing > the same problem, right? If so, then presumably the same copy of the C > library is involved in both cases. Yes, and I don't doubt that the mingw.org compilers and my MSVC++7.0 compiler are using the same copy of the C library - it's just that I *thought* that the 32-bit mingw64 compilers (which produce no discrepancies) would *also* be using the *same* C library. If someone can authoritatively tell me that's not so, then it's "puzzle solved" !! And if the mingw compilers are bound to this unsatisfactory C library, then I think I'll probably end up migrating to the the 32-bit mingw64 compiler .... which would be rather unfair towards mingw.org, given that it's not their fault. I'm not really set up to apply the same testing to the MSVC++ 7.0 compiler but I have tested a number of values for which strtod() rounds incorrectly when using mingw's gcc, and found the same behaviour with MSVC++7.0. > The reason (at least if I > remember your previous posts correctly) for the error not existing in > previous versions of 32-bit gcc ...... As regards mingw.org compilers, the discrepancies exist on both gcc-3.4.5 and gcc-4.7.0. That's the only 2 versions for which I have results. Thanks Jared. Cheers, Rob |