Sample code: struct data { int a[50]; }; class C { public: void mem(data p); }; void C::mem(data p) { } int main(int argc, char **argv) { C c; data p; for (int i = 0; i < 20000000; ++i) c.mem(p); return 0; } Reproducible: Always Steps to Reproduce: 1. Compile above code as follows: gcc -Wall test.cc -o test 2. Run as follows, noting the 'user' time: time ./test 3. Now compile with -O2: gcc -Wall -O2 test.cc -o test 4. Note the 'user' time with optimisation: time ./test Actual Results: The first run of the program took ~ 2.9s user time, while the second run took ~5.3s user time. Expected Results: The two runs should have taken approximately the same amount of time, with the optimised version being at most a few percent slower than the unoptimised version. I understand that optimisation sometimes decreases speed, but it should never cause a 100% decrease in speed. Since most components of a Gentoo system are compiled with optimisation, this has the potential to seriously affect system performance. Using stock gcc-3.3.4 on another system, the second run of the same program was slightly faster, as expected. Maybe an upstream bug, or maybe Gentoo specific; I haven't tried a stock gcc-3.3.5. The problem affects passing structs, etc. by value (on the stack). If the parameter to mem() is given as a reference, the optimised version is slightly faster. While passing structs, etc. by value is generally bad programming practice, it is still done sometimes and is sometimes necessary. (Though the fact that it shouldn't be common in most shipping code reduces the severity of this problem, obviuosly.) emerge info: Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.4.20041102-r1, 2.6.11.10 i686) ================================================================= System uname: 2.6.11.10 i686 Intel(R) Pentium(R) M processor 1.60GHz Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.5 [2.3.5 (#1, May 18 2005, 02:09:25)] dev-lang/python: 2.3.5 sys-apps/sandbox: [Not Present] sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-DV1" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium3 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X alsa apm avi berkdb bitmap-fonts cdr crypt cups curl dba doc dvd emboss encode esd fam foomaticdb fortran freetype gd gdbm gif gnome gpm gtk gtk2 icq imap imlib ipv6 jabber jpeg ldap libg++ libwww mad mikmod mmx motif mozilla mp3 mpeg msn ncurses nls ogg oggvorbis opengl oss pam pdflib perl png python quicktime readline sdl session smooth spell sqlite ssl svga tcpd tetex theora tiff truetype truetype-fonts type1-fonts vorbis xft2 xine xml2 xmms xosd xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
how does 3.3.6 fair
Same problem with 3.3.6 (using the ebuild that's currently in portage).
I doubt this is gentoo specific. Also, 3.3 isn't being maintained upstream any more (3.3.6 was the final release). How does 3.4 fair with this? If you notice similar behavior with 3.4, I'd recommend filing an upstream bug.
