While performing 'emerge -e system' after gcc upgrade to 4.1.2, dev-libs/gmp-4.2.2 failed the test 't-export' while building (FEATURES="test" is enabled). When emerge dev-libs/gmp was re-run by itself the build failed on the same test. Output: ... PASS: t-import wrong result data at data[0] align=0 src "0" src=0x0 order=1 size=1 endian=1 nail=0 want count 0 got count 0 want got /bin/sh: line 4: 28469 Aborted ${dir}$tst FAIL: t-export ... Will attach full build.log. Reproducible: Always Steps to Reproduce: 1. enable FEATURES="test" 2. emerge "=dev-libs/gmp-4.2.2" Actual Results: test 't-export' fails in make check. Expected Results: All tests succeed and software successfully installs. ~ # emerge --info Portage 2.1.3.19 (default-linux/x86/2007.0/desktop, gcc-4.1.2, glibc-2.6.1-r0, 2.6.14-gentoo-r5rith i686) ================================================================= System uname: 2.6.14-gentoo-r5rith i686 Celeron (Coppermine) Timestamp of tree: Sat, 19 Jan 2008 09:30:06 +0000 app-shells/bash: 3.2_p17-r1 dev-lang/python: 2.4.4-r6 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.11.13-r1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.9.6-r2, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium3 -funroll-loops -finline-functions -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -march=pentium3 -funroll-loops -finline-functions -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer sandbox sfperms strict test unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="acl acpi bitmap-fonts bzip2 cairo cdr cli cracklib crypt cscope cups dbus dri dvd dvdr dvdread eds emboss encode evo fam firefox gif gstreamer hal iconv isdnlog jpeg mad midi mikmod mmx mp3 mpeg mudflap ncurses nptl nptlonly ogg openmp pam pcre pdf png pppd qt3 qt3support qt4 quicktime reflection sdl session spell spl sse ssl svg test tiff truetype-fonts type1-fonts vim-syntax vorbis win32codecs x86 xml 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 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 evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="apm ark chips cirrus cyrix dummy fbdev glint i128 i740 i810 imstt mach64 mga neomagic nsc nv r128 radeon rendition s3 s3virge savage siliconmotion sis sisusb tdfx tga trident tseng v4l vesa vga via vmware voodoo" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Created attachment 141316 [details] Full build.log from attempted emerge.
Try w/ sane C[XX]FLAGS, like "-O2 -march=pentium3 -pipe" and it will work...
(In reply to comment #2) > Try w/ sane C[XX]FLAGS, like "-O2 -march=pentium3 -pipe" and it will work... > I can now confirm, having tried, that gmp emerges successfully with the suggested CFLAGS. I do not 'typically' find that either -funroll-loops or -finline-functions causes problems in most code. For instance, -fomit-frame-pointer tends to break more things. I will attempt to re-emerge with each of those flags set individually to see if I can isolate the problematic flag. Despite the fact that removing those flags corrects the issue, perhaps the problematic flag should be masked in the ebuild?
Tested individually adding -funroll-loops -finline-functions to CFLAGS. -funroll-loops is the culprit CFLAG, emerges fine with -finline-functions. Suggest adding 'filter-flags -funroll-loops' to ebuild, i.e.: # diff -u gmp-4.2.2.ebuild gmp-4.2.2-r1.ebuild --- gmp-4.2.2.ebuild 2008-01-19 19:33:00.000000000 +0000 +++ gmp-4.2.2-r1.ebuild 2008-01-19 19:42:34.000000000 +0000 @@ -34,6 +34,7 @@ src_compile() { # GMP believes hppa2.0 is 64bit + filter-flags -funroll-loops local is_hppa_2_0 if [[ ${CHOST} == hppa2.0-* ]] ; then is_hppa_2_0=1
as per url funroll-loops is prone with faults. Other documentation indicates that funroll-loops as a concept make stuff slower. as such i'm not going to fix this.
(In reply to comment #5) > as per url funroll-loops is prone with faults. Other documentation indicates > that funroll-loops as a concept make stuff slower. > as such i'm not going to fix this. The 'fix' I suggested, and gave the change for, would be to filter (i.e. remove if set) that particular cflag. This would allow a system which used this cflag (successfully with most software) to emerge gmp and have gmp build successfully by disabling this flag. I can understand not attempting to troubleshoot the specific reason for the issue or fix that, but refusing to automatically filter out the problematic flag such that the emerge fails strikes me as rather poor engineering. Filtering problematic flags like this is normal/common within gentoo ebuilds.
the basis for your assumptions is shaky. you just happened to notice a failure in *one* package because it had a test case. you could easily have other packages silently and subtly breaking due to your global usage of this flag. filtering it in one place doesnt solve the real issue. flag filtering is not normal/common and is actively discouraged.
(In reply to comment #7) > the basis for your assumptions is shaky. you just happened to notice a failure > in *one* package because it had a test case. you could easily have other > packages silently and subtly breaking due to your global usage of this flag. > filtering it in one place doesnt solve the real issue. > flag filtering is not normal/common and is actively discouraged. This is probably a valid objection. Certainly, it is valid from a provably correct engineering standpoint. I have used -funroll-loops on many software packages for many years, and had very few errors which I have ever traced to its use. That does not prove however, that undetected errors may not have occur. Point well made, and accepted. It is difficult to prove the absence of errors, showing the presence of them can be hard enough. My apologies for being incorrect regarding flag filtering. I have used gentoo on and off since 2004. I could no longer point to reference material, and the recommendations may since have changed, but I remember reading at least one 'official' document suggesting flag filtering. I also recall the longstanding recommendation of including -fomit-frame-pointer in the suggested flags in the handbook... a flag which I have found to break many packages over the years. From an engineering standpoint, I see only a few alternatives: 1) Leave the user on his/her own to experiment with what does and does not break specific packages with no guidance. 2) Have a base set of 'supported' CFLAGS and ensure that all regressions which occur with these flags are either corrected at a source level, or filtered by the ebuilds. 3) Forcibly filter all flags which are arbitrarily deemed questionable across all packages, potentially harming the performance of packages for which these flags are fine. 4) Filter flags which are known to cause problems for certain packages on those specific packages and those only. I will admit that I may be missing something, but option #4 seems to me to be the most usable. Option #2 would also seem like it had some viability to me. I am in favor, in general, of allowing the typical user to successfully emerge a large set of packages without having to investigate failed emerges many times along the way and resume the emerge. While it has been some time since I performed the emerge during which I encountered this issue and opened this bug, the number of issues which I encountered when using the test cases and emerging the base system package set amazed me at the time. I would think that the stability and ease of emerging the packages in the system set would be one of the highest engineering goals for the project.
if you hark from that long ago, then your recollection is fairly accurate. "back in the day", flag filtering was a very common method for "fixing" compiler bugs. we'd add filters to ebuilds all over the place and close bugs, but never actually get the compiler fixed. we'd only patch over packages where we noticed a bug. that, however, is no longer the status quo. flag filtering in packages is hardly maintainable (especially across gcc versions). instead we focus on getting the bugs fixed at their source.
Thanks for the additional info. I am pleased that the engineering approach to this class of problem has matured a bit, and I think that the 'fix-it-at-the-source' approach is far better, long-term. It's also a harder one to implement properly. At least if I understand you correctly, this means that the available responses to the specific issue are fairly few. I would argue that the "don't use that CFLAG" solution, as a documentation admonition, is roughly equivalent to system-wide filtering of the flag. It fails the basic test of fixing the core issue. Whether the -funroll-loops option, properly implemented, improves performance is apparently subject to debate. I do program at a very low (including assembly language) level, and I have read many engineering documents, including the optimization guides from Intel and AMD suggesting loop unrolling. If you unroll a loop *while keeping it small enough to fit in the L1 cache* then you will (obviously) have increased the code size, but also increased the performance. This is due to the avoidance of (particularly conditional) branches and the accompanying pipeline stalls that may be incurred. With newer architectures moving to larger and larger caches, I believe this optimization is only now coming into its prime. Setting aside however, whether or not it improves performance, it is a documented, available option. If we are to adhere to fixing the core problem, we need to either: 1) Trace this issue to a subtle flaw in either the gmp code or the test case code and resolve it there. 2) Trace this issue to a gcc bug and re-assign the bug against gcc. Marking it as closed without doing either is inferior to filtering the problematic flag, as it does not provide even a temporary fix for the end user. I believe that the average user would be far happier to have his/her emerges work than to need to look up bugs online only to find that they stem from usage of a CFLAG, and had been closed without action.
The test fails for me with CFLAGS="-O3 -march=prescott -pipe -mmmx -msse -msse2 -msse3", same flags with -O2 work fine. It's the same test that fails.
Seems fine with gcc-4.3
