Your message dated Sat, 18 Jun 2016 00:52:54 +0200 with message-id <[email protected]> and subject line closing bugs reported against ancient GCC versions has caused the Debian Bug report #470318, regarding gcc seems to produce wrong assembly for floating point division (rounding) to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 470318: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=470318 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: gcc-4.3 Version: 4.3.0-1 Severity: normal --- Please enter the report below this line. --- Hi, the following code: $ cat quot.c #include <stdio.h> int main() { double a = -4.1974624032366689e+117; double b = -8.4657370748010221e-47; double c = a/b; printf("%.16e\n%.16e\n%.16e\n",a, b, c); return 0; } when compiled: $ gcc -W -Wall quot.c and run without -O: $ ./a.out -4.1974624032366689e+117 -8.4657370748010221e-47 4.9581771393902231e+163 and with -O: $ gcc -W -Wall -O quot.c $ ./a.out -4.1974624032366689e+117 -8.4657370748010221e-47 4.9581771393902237e+163 produces different results in the last digit. The "-O" case is correct. That is because the -O option uses MPFR to calculate the (correct) result at compile time, as can be checked in the assembly. This only happens on 32 bits (intel core 2 duo), it doesn't happen when using Debian amd64 (gcc produces a different, correct, assembly there). A lot more information, together with how this was discovered can be found here: http://code.google.com/p/mpmath/issues/detail?id=22 you can also find the assembly codes in there. Note, that MSVC produces the correct 32 bit assembly, see the issue, that's why I think the problem is not in my processor, but rather in gcc. I tried gcc-3.4, gcc-4.1, gcc-4.2, gcc-4.3 and gcc-snapshot. No difference. However, I am not an expert in this at all - maybe I did something wrong. Please ask if you need more information. I'd like to trace this bug down and figure out if it's a bug in gcc, or somewhere else. Ondrej --- System information. --- Architecture: i386 Kernel: Linux 2.6.24-1-686 Debian Release: lenny/sid 500 unstable ftp.cz.debian.org --- Package information. --- Depends (Version) | Installed =====================================-+-===================== binutils (>= 2.17cvs20070426) | 2.18.1~cvs20080103-1 cpp-4.3 (= 4.3.0-1) | 4.3.0-1 gcc-4.3-base (= 4.3.0-1) | 4.3.0-1 libc6 (>= 2.7-1) | 2.7-9 libgcc1 (>= 1:4.3.0-1) | 1:4.3.0-1 libgomp1 (>= 4.3.0-1) | 4.3.0-1
--- End Message ---
--- Begin Message ---This bug has been reported against an ancient version of gpc (4.1), gcc/g++/gfortran (4.3), or gcj/gij/gobjc (4.4), that was last released with Debian 6.0 (squeeze). But even squeeze-lts has now reached end-of-life and is no longer supported. The bug is assumed to be fixed (or no longer relevant) in newer GCC releases and therefore I'm closing this report now. If the problem is still reproducible in the currently supported versions (gcc-5, gcc-6 or corresponding g++/gcj), feel free to provide more information, reopen and reassign this bug report. Andreas
--- End Message ---
