When trying to compile gst-plugins, gcc reproducibly dies with an internal compiler error in codec.c. Given that it always dies at the same spot I don't suspect a hardware issue. Reproducible: Always Steps to Reproduce: 1. emerge gst-plugins Actual Results: codec.c: In function `DecodeAC': codec.c:286: internal compiler error: Floating point exception Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://bugs.gentoo.org/> for instructions. Preprocessed source stored into /var/tmp/portage/gst-plugins-0.6.4/temp/ccytepMl.out file, please attach this to your bugreport make[3]: *** [libgstmpeg1encoder_la-codec.lo] Error 1 make[3]: Leaving directory `/var/tmp/portage/gst-plugins-0.6.4/work/gst-plugins-0.6.4/gst/mpeg1enc' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/gst-plugins-0.6.4/work/gst-plugins-0.6.4/gst' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/gst-plugins-0.6.4/work/gst-plugins-0.6.4' make: *** [all] Error 2 !!! ERROR: media-libs/gst-plugins-0.6.4 failed. !!! Function src_compile, Line 78, Exitcode 2 !!! (no error message) Expected Results: gst-plugins should have emerged successfully. [problematic source is attached in attachment] ====emerge info output==== Portage 2.0.50-r1 (default-x86-1.4, gcc-3.3.2, glibc-2.3.3_pre20040207-r0, 2.6.2-rc2) ================================================================= System uname: 2.6.2-rc2 i686 AMD Athlon(tm) XP 2000+ Gentoo Base System version 1.4.3.13 Autoconf: sys-devel/autoconf-2.59 Automake: sys-devel/automake-1.8.2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O3 -march=athlon-xp -msse -mmmx -m3dnow -momit-leaf-frame-pointer -fomit-frame-pointer -funroll-loops -ffast-math -fprefetch-loop-arrays -freduce-all-givs -finline-limit=600 -mfpmath=387 -fprefetch-loop-arrays -fforce-addr -maccumulate-outgoing-args -fmove-all-movables -ftracer -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /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/env.d" CXXFLAGS="-O3 -march=athlon-xp -msse -mmmx -m3dnow -momit-leaf-frame-pointer -fomit-frame-pointer -funroll-loops -ffast-math -fprefetch-loop-arrays -freduce-all-givs -finline-limit=600 -mfpmath=387 -fprefetch-loop-arrays -fforce-addr -maccumulate-outgoing-args -fmove-all-movables -ftracer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://ftp.snt.utwente.nl/pub/os/linux/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow X aalib alsa apm arts avi berkdb cdr crypt cups doc encode esd foomaticdb gdbm gif gnome gpm gtk gtk2 imlib java jpeg kde libg++ libwww mad mikmod mmx motif mozilla mpeg ncurses nls nptl oggvorbis opengl oss pam pdflib perl png python qt quicktime readline samba sdl slang spell sse ssl svga tcltk tcpd tetex truetype usb x86 xinerama xml2 xmms xv zlib"
Created attachment 25708 [details] The preprocessed source that gcc trips over.
Besides the obvious 'scale down your CFLAGS' - it works fine here with gcc-3.3.3. What gcc version?
I did some (well lots) of searching on the forums and eventually found this thread: http://forums.gentoo.org/viewtopic.php?t=68686 This explains that the issue is a compiler issue related to some overflow in gcc's loop optimizer. That forum also links to a gcc bug report http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13318 which explores the issue leading to a fix (at least as I understand it) http://gcc.gnu.org/ml/gcc-patches/2003-12/msg00629.html The fix will probably just propagate through portage sometime. However I just used the work-around and disabled "-fprefetch-loop-array" which works for me.
I forgot to mention which gcc version this is, well it's Thread model: posix gcc version 3.3.3 20040217 (Gentoo Linux 3.3.3, propolice-3.3-7) as per gcc -v
It was already applied for gcc-3.3.2-r5 ...
OK well that's funny... - if you look at the original CFLAGS I posted; I had accidentally listed -fprefetch-loop-arrays twice... this seems to be crucial (this never gets passed to gcc though as far as I can see I think the ebuild filters out -fprefetch-loop-array to avoid the error perhaps but only catches the first one???). Incidentally libfame-0.9.0 exhibits the same behaviour and is much smaller and faster to compile. Anyhow I took the preprocessed source in libfame that caused the error, and compiled on the command line: gcc -msse -fprefetch-loop-arrays -march=i586 -c bla2.c -fstrength-reduce -O This commandline generates an ICE; removing the msse complains that this arch doesn't support fprefetch... and upping the march to i686 or higher causes the compile to complete successfully; finally without -fstrength-reduce the compiler doesn't crash either, and without -O the compiler doesn't crash either. I suspect the crucial option within -O is -floop-optimize since appending -fno-loop-optimize prevents the crash and taking the options that gcc supposedly turns on with -O (namely "-fdefer-pop -fmerge-constants -fthread-jumps -floop-optimize -fcrossjumping -fif-conversion -fif-conversion2 -fdelayed-branch -fguess-branch-probability -fcprop-registers") and turning them all off (prepending no-) still won't prevent the crash. Finally, using only -floop-optimize instead of -O doesn't trigger the ICE (perhaps because gcc doesn't optimize at all then?). So it looks as though newer arches are fixed, but -i586 (which isn't -fprefetch-loop-arrays compatible in the first place) isn't, but the compiler can be convinced to use -fprefetch-loop-arrays with -msse despite the arch. lib-fame seems to append -march=i586 (I don't know why) to the CFLAGS. The redundant -msse permits -fprefetch-loop-arrays where -march=i586 wouldn't otherwise, and the second -fprefetch-loop-arrays gets past the filter in the ebuild (in the src_compile function). Basically I was really unlucky and this bug won't bite other gentoo users very easily. However the gcc ICE still exists you can easily verify it by downloading the attached preprocessed source and compiling it with the options listed above.
I fixed libfame to remove -march=i586, so that should be fixed. For gst-plugins we need to fix filter-flags. Mike, please have a look (as I think you added the 'fancy spacing' stuff to filter-flags, etc). His -fprefetch-loop-arrays is terminated with a line break, so the spacing do not work. I would maybe recommend doing: CFLAGS="$(echo "${CFLAGS}" | gawk '{ flag = ENVIRON["x"] # get $x split($0, args) for (x in args) if (args[x] == flag) $x = "" print }')" or something similar.
hey solar, maybe you can take a peek at this filter-flags oddity, i know you like getting your hands into this muddy waters :-) thanks in advance, my friend
so is there still an issue here ? the ebuilds have the correct filter-flags now, and filter-flags should process multiple occurences of the same flag ... in terms of having a line break in CFLAGS ... guess that's still broken ?
closing due to inactivity.
