Portage 2.1.6.13 (!../var/cache/portage/tree/profiles/default/linux/x86/2008.0, gcc-4.4.0-asneeded, glibc-2.10.1-r0, 2.6.30-gentoo-r1 i686) ================================================================= System uname: Linux-2.6.30-gentoo-r1-i686-Quad-Core_AMD_Opteron-tm-_Processor_2350-with-gentoo-2.0.1 Timestamp of tree: Mon, 06 Jul 2009 16:30:01 +0000 ccache version 2.4 [enabled] app-shells/bash: 4.0_p24 dev-java/java-config: 1.3.7-r1, 2.1.8-r1 dev-lang/python: 2.6.2-r1 dev-python/pycrypto: 2.0.1-r8 dev-util/ccache: 2.4-r8 dev-util/cmake: 2.6.4 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.4.3-r3 sys-apps/sandbox: 2.0 sys-devel/autoconf: 2.13, 2.63-r1 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2, 1.11 sys-devel/binutils: 2.19.1-r1 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.30 ACCEPT_KEYWORDS="x86 ~x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /opt/glftpd/etc /opt/glftpd/ftp-data /opt/openfire/resources/security/ /opt/openjms/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/bufrtables /usr/share/config /var/bind /var/lib/hsqldb /var/phxd /var/qmail/alias /var/qmail/control /var/spool/torque /var/vpopmail/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/eselect/postgresql /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -pipe" DISTDIR="/var/cache/distfiles" FEATURES="ccache distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict test test-fail-continue unmerge-orphans userfetch" GENTOO_MIRRORS="http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ http://ftp.uni-erlangen.de/pub/mirrors/gentoo" INSTALL_MASK=" /usr/share/doc /usr/share/man /usr/share/info" LDFLAGS="-Wl,-O1" MAKEOPTS="-j14" PKGDIR="/var/spool/portage/packages" PORTAGE_COMPRESS="" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/var/cache/portage/tree-tinderbox" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="acl berkdb bzip2 cli cracklib crypt cups dri fortran gdbm gpm iconv ipv6 isdnlog java5 java6 midi mudflap ncurses nls nostatic nptl nptlonly openmp pam pcre perl pppd python qt3support readline reflection ruby session spl ssl sysfs tcpd unicode x86 xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, LANG, LC_ALL, LINGUAS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Created attachment 196931 [details] Build log
bug in glibc. its 32bit double math isnt as good as the 64bit version. $ cat test.c #include <math.h> #include <stdio.h> #define PI 3.14159265358979323846 main() { double x = PI / 2; printf("%-16.16g\n", cos(x)); } $ gcc test.c -lm -o 32 -m32 $ gcc test.c -lm -o 64 $ ./32; ./64 6.123031769111886e-17 6.123233995736766e-17
(In reply to comment #2) > bug in glibc. its 32bit double math isnt as good as the 64bit version. > > $ cat test.c > #include <math.h> > #include <stdio.h> > #define PI 3.14159265358979323846 > main() { double x = PI / 2; printf("%-16.16g\n", cos(x)); } > > $ gcc test.c -lm -o 32 -m32 > $ gcc test.c -lm -o 64 > $ ./32; ./64 > 6.123031769111886e-17 > 6.123233995736766e-17 (For reference, I get the same results.) Disassembling the output shows that the 32-bit version uses the FPU, and the 64-bit version uses the SSE registers. Compiling with -mfpmath=sse on 32-bit doesn't cause different results though ./testpi-32: 6.123031769111886e-17 ./testpi-32-sse: 6.123031769111886e-17 ./testpi-64: 6.123233995736766e-17 FYI, the program on alpha returns 6.123233995736766e-17 as well. Now, there's a define in math.h, M_PI_2. It seems that if and only if you call cos(M_PI_2) (ie, not "double x = M_PI_2; cos(x)") the 32-bit versions (SSE and FPU) give better correct results. #include <math.h> #include <stdio.h> main() { printf("%-16.16g\n", cos(x)); } Now, let's all realize that _all_ of these answers are wrong. cos(pi/2) is 0. So while the discrepancy between the 32/64-bit versions is strange, I cannot imagine any software depends on cos(PI/2) returning a result more accurate than either of the results we've seen. By my math, the 32-bit value only differs by 0.0033%. So, is there really a bug here to fix?
i'm not sure your cos(M_PI_2) test is doing what you think it is ... are you sure gcc didnt optimize it away using its much more accurate mpfr/gmp library ?
(In reply to comment #4) > i'm not sure your cos(M_PI_2) test is doing what you think it is ... are you > sure gcc didnt optimize it away using its much more accurate mpfr/gmp library ? Yes, after looking at objdump, in fact it is optimizing the cos call completely out. Unfortunate that it can't detect that cos(M_PI_2) can be represented a bit better and more precisely than 6.123233995736766e-17.
so the latest glibc-2.21 has gotten much better: $ ./32; ./64 6.123233995736766e-17 6.123233995736766e-17 if it comes up again, i might re-evaluate the test. i understand a bit more that libm is hard to get "right", especially when there is no actual definition of "right" in the floating point world. i might have to truncate the test output down to a few significant digits. but i'm lazy and it's easier to punt ;).
*** Bug 794985 has been marked as a duplicate of this bug. ***
