Slashdot Mirror

← Back to Stories (view on slashdot.org)

MinGW and MSVCRT Conflict Causes Floating-Point Value Corruption

Posted by timothy on from the internal-conflict dept.

jones_supa writes: If you are working on a C++ program where you need very accurate floating point numbers, you might have decided to use long double data type for the extra precision. After a few calculations, you happen to print your number. To your shock, instead of the number being 123.456789, it is printed out as -6.518427 × 10^264 (or 2.745563 depending on your computer). This is actually a bug in some versions of MinGW g++ 4.8.1 (MinGW is a port of GNU programming tools for Windows). Microsoft's C++ runtime library reserves 80 bits for double and long double. When MinGW uses the Microsoft DLL to print out the value, the number is interpreted as using only 64 bits. This discrepancy causes garbage results to be output.

5 of 98 comments (clear)

  1. Re:Surprised? by TheRaven64 · · Score: 5, Informative

    It's an ABI mismatch, and the summary is nonsense, saying almost the exact opposite of TFA (which I actually read, because the summary is obvious nonsense). The issue is that the Windows ABI defines long double as being a 64-bit floating point value (which is fine, because the only requirement for long double is that it have no less precision than double. If you're using it and expecting some guaranteed precision for vaguely portable code then you're an idiot). For some reason, MinGW (which aims to be ABI-compatible with MS, at least for C libraries) uses 80-bit x87 values for long double, so you get truncation. I forget the exact calling conventions for Windows i386, but I believe that in some cases this will be silently hidden, as the value will be passed in x87 register and so be transparently extended to 80 bits in the caller and truncated in the callee anyway. It's only if it's passed on the stack (or indirectly via a pointer) that it's a problem.

    It's not obvious which definition of long double is better. On modern x86, you'll use SSE for 32- and 64-bit values, and may lose precision moving between x87 and SSE registers. You also get worse IEEE compliance out of the x87 unit, which may matter more than the extra 16 bits of precision. 80-bit floats are not available on any platform other than x86 (128-bit is more common, though PowerPC has its own special non-IEEE version of these and on some other platforms they're entirely done in software), so they're a bad choice if you want portable code that generates the same output on different platforms.

    --
    I am TheRaven on Soylent News
  2. Well, from Dice's perspective... by Anonymous Coward · · Score: 5, Informative

    ... this is better than posting stories about SourceForge getting caught highjacking the dev accounts of major OSS projects I guess.

    1. Re: Well, from Dice's perspective... by Anonymous Coward · · Score: 5, Informative

      The account was hijacked. They locked the gimp-win developer out of his account in order to add malware to an open source project. This is big news, but because it's SlashdotMedia doing the shenanigans, it won't appear on the front page. That's pretty stunning that a tech news site censors the most important tech news of the day, but that's what is going on.

  3. Re: Surprised? by jones_supa · · Score: 5, Informative

    Which means it's a 100% windows bug

    No. The MinGW version of GCC allowed to compile programs against the Microsoft C++ runtime library, but the compiler created code which did not follow the spec of the Microsoft library. There really isn't anything to blame about Windows here.

  4. exactly by rewindustry · · Score: 5, Informative

    SourceForge, the code repository site owned by Slashdot Media, has apparently seized control of the account hosting GIMP for Windows on the service, according to e-mails and discussions amongst members of the GIMP community—locking out GIMP's lead Windows developer. And now anyone downloading the Windows version of the open source image editing tool from SourceForge gets the software wrapped in an installer replete with advertisements.

    http://arstechnica.com/informa...

    The GIMP developers aren't happy at all about this. They say that Sourceforge impersonated the GIMP developers, and abused the trademarks owned by the GNOME foundation.

    https://mail.gnome.org/archive...