When optimisations are on (-On, n >= 1), gcc-4.3.2-r3 compiles a fairly straightforward piece of C code into an incorrect binary. Reproducible: Always Steps to Reproduce: 0. Compile the code. Actual Results: gcc produces an incorrect binary. Expected Results: gcc produces a correct binary. Today I tried to solve a problem from the Northwestern-Europe Regional from ACM ICPC 2001 whose statement is very simple and can be found here (http://acm.pku.edu.cn/JudgeOnline/problem?id=1265). I wrote the following code in order to obtain a solution: /* * Area * source = ACM ICPC 2001 - Northwestern Europe * difficulty = medium * keywords = geometry number-theory */ #include <stdio.h> static int gcd(int a, int b) { int r; if (a < 0) a = -a; if (b < 0) b = -b; while (b != 0) { r = a%b; a = b; b = r; } return a; } int main(void) { int tc, cs; int x0, y0, x1, y1, dx, dy; int n, i; int l; int area; scanf("%d", &tc); for (cs = 0; cs != tc; ++cs) { scanf("%d", &n); x0 = 0; y0 = 0; l = 0; area = 0; for (i = 0; i != n; ++i) { scanf("%d%d", &dx, &dy); l+= gcd(dx, dy); x1 = x0 + dx; y1 = y0 + dy; area+= x0*y1 - x1*y0; x0 = x1; y0 = y1; } if (area < 0) area = -area; printf("Scenario #%d:\n", cs+1); printf("%d %d %d.%d\n\n", (area+2-l)/2, l, area/2, area&1 ? 5 : 0); } return 0; } It is just an application of Pick's Theorem, the standard formula for computing the area of a polygon and the trivial algorithm for computing the greatest common divisor of two integers. Anyway, I believe gcc is incorrectly compiling the cross product of the vectors (x0, y0) and (x1, y1) in the line area+= x0*y1 - x1*y0; Here are my results: $ cat a.in 2 4 1 0 0 1 -1 0 0 -1 7 5 0 1 3 -2 2 -1 0 0 -3 -3 1 0 -3 $ cc a.c $ ./a.out <a.in Scenario #1: 0 4 1.0 Scenario #2: 12 16 19.0 $ cc a.c -O $ ./a.out <a.in Scenario #1: -1 4 0.0 Scenario #2: -7 16 0.0 $ I inserted some printf's in the code to actually see gcc is simply ignoring the computation of `area'. Any ideas on the source of this behaviour? Thank you for your attention. P.S.: I consider this bug severe for it is a bug in the toolchain, thus all my system is vulnerable to it. $ emerge --info Portage 2.1.6.13 (default/linux/x86/2008.0, gcc-4.3.2, glibc-2.9_p20081201-r2, 2.6.30-rc7 i686) ================================================================= System uname: Linux-2.6.30-rc7-i686-Intel-R-_Pentium-R-_M_processor_1.50GHz-with-glibc2.0 Timestamp of tree: Sat, 27 Jun 2009 15:00:01 +0000 app-shells/bash: 3.2_p39 dev-lang/python: 2.5.4-r2 dev-util/cmake: 2.6.4 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.13, 2.63 sys-devel/automake: 1.5, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium-m -mmmx -msse -msse2 -O2 -fomit-frame-pointer -pipe -Wall" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-march=pentium-m -mmmx -msse -msse2 -O2 -fomit-frame-pointer -pipe -Wall" DISTDIR="/sources" FEATURES="distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LDFLAGS="-Wl,-O1" PKGDIR="/usr/portage/packages" 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="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acpi alsa bash-completion berkdb bzip2 cairo cli cracklib crypt dga dri fortran gdbm gif gmp gpm iconv ipv6 isdnlog jpeg jpeg2k laptop latex lcms lzma midi mmx mp3 ncurses nptl nptlonly openal opengl openmp pam pdf png pppd readline reflection rtc sdl session spl sqlite sse sse2 ssl svg sysfs tcpd theora truetype unicode urandom vim-syntax vorbis wifi x86 xcb xorg xvid 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" INPUT_DEVICES="keyboard mouse synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="intel" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY $
Could you please attach this code for convenience sake ? BTW, this affects gcc 4.4.0 too.
Created attachment 196387 [details] The Test Case
Created attachment 196389 [details] an amusing bug Now, that really silly. Following attachment is your code + 2 commented lines. As you may notice, those two area lines are arithmetically equal. Simply exchanging those two lines does nothing. However if both those lines are exchange AND printf line is uncommented, code works. If however only the printf line is uncommented, but the exchange is not made, bug still happens.
Could you confirm my result, as I was using 4.4.0 ?
Upstream says: Can't reproduce in any active branch, thus already fixed for 4.5.0, 4.4.1, 4.3.4 Though they're not saying when exactly it got fixed. Also, it works correctly in 4.1.2.
(In reply to comment #4) > Could you confirm my result, as I was using 4.4.0 ? > Result confirmed.
I'm trying to hunt down the commit on the 4.4 branch that fixes this. Then I'll find it on 4.3 as well.
So, 4.4.1 got released today. Once it gets into the tree, we'll see if it really fixes this problem. Though backporting to stable will still be a problem, till a new release of 4.3 branch.
OK, 4.4.1 works with 4.4.0 1.0 patch tarball. It does fix this problem. But, as already said, that's not really helpful for stable.
IMOP, gcc-4.3.2 should be masked as soon as possible. Let's stay with gcc-4.1.2 stable or stabilize gcc-4.3.4. I have built all my system with gcc-4.3.2 :) Let's pray for this bug doesn't affects anything critical.
If this is the same bug that affects GCC 4.4.0, I've seen it hit production code. I agree, gcc-4.3.2 needs to be fixed or get masked ASAP. I wouldn't be surprised if this is causing bugs or instability in packages.
I think you've missed what I've said - while 4.4.1 does have its own bugs (like i.e. tree vectorizing one), this particular one is fixed.
I'm talking about this bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40747 4.4.0 had it, 4.4.1 fixed it. We were using 4.4.0 for some stuff and it hit real, production code. However, the testcase in that bug report does not fail with 4.3.2-r3, so I think we're talking about different (related?) bugs. Has the bug that this report is about been located in the GCC bugtracker?
fixed versions are in stable, so we're not going to spend time on older ones
