this is a spin off of bug #104189 and further details also can be found there. in summary: xine-lib-1.1.0-r3 fails to build on x86 machines running GCC 4.0.1. this is due to the patch 100_all_noextraflags.patch that was added in -r2 which removes the upstream default of building x86 without PIC. when the build reaches the ffmpeg stage of the compile, it bails with this error: i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../../../.. -I../../../.. -I../../../../include -I../../../../include -I../../../../src -I../../../../src/xine-engine -I../../../../src/xine-engine -I../../../../src/xine-utils -I../../../../src/input -I../../../../src/input -I../../../../lib -DSIMPLE_IDCT -DHAVE_AV_CONFIG_H -DRUNTIME_CPUDETECT -DUSE_FASTMEMCPY -DCONFIG_RISKY -DCONFIG_DECODERS -DXINE_MPEG_ENCODER -DCONFIG_ZLIB -DNDEBUG -D_REENTRANT -DXINE_COMPILE -O2 -march=pentium4 -fomit-frame-pointer -pipe -fno-ident -frename-registers -ffunction-sections -mno-sse -fomit-frame-pointer -c dsputil_mmx.c -fPIC -DPIC -o .libs/dsputil_mmx.o h264dsp_mmx.c: In function 'h264_h_loop_filter_luma_mmx2': dsputil_mmx.c:618: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' dsputil_mmx.c:618: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' make[5]: *** [dsputil_mmx.lo] Error 1 make[5]: Leaving directory `/var/tmp/portage/xine-lib-1.1.0-r2/work/xine-lib-1.1.0/src/libffmpeg/libavcodec/i386' the only solution that i can find to fix this is to build without -fPIC. this is what Debian and Fedora do, and what upstream recommends for x86. on other arches of course, -fPIC is necessary to build shared libraries. see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=115006 for all the dirty details. building without PIC enabled conflicts with hardened's needs, however. see bug #100552 for just one example of their efforts to whip xine-lib into shape. so this solution might not be the best, but i don't have another handy. considering gcc4 doesn't have a hardened flavour, i don't think it would interfere too much if it were made conditional. in any case, adding --disable-fpic to the build allows it to complete safely.
Portage 2.0.51.22-r2 (default-linux/x86/2005.1, gcc-4.0.1-20050901, glibc-2.3.5.20050722-r0, 2.6.13-ck1 i686) ================================================================= System uname: 2.6.13-ck1 i686 Mobile Intel(R) Pentium(R) 4 CPU 3.06GHz Gentoo Base System version 1.12.0_pre8 ccache version 2.4 [enabled] dev-lang/python: 2.4.1-r1 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6 sys-devel/binutils: 2.16.1, 2.16.91.0.3 sys-devel/libtool: 1.5.20 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=prescott -fomit-frame-pointer -pipe -mfpmath=sse -fno-ident" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=prescott -fomit-frame-pointer -pipe -mfpmath=sse -fno-ident -fvisibility-inlines-hidden" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks sandbox sfperms" GENTOO_MIRRORS="http://gentoo.chem.wisc.edu/gentoo/" LDFLAGS="-Wl,-O1" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/home/dirtyepic/overlay" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X aac acpi alsa avi bash-completion berkdb bzip2 cddb cdr crypt curl dbus divx4linux dts dvd dvdr dvdread encode exif ffmpeg firefox flac gdbm gif gnutls gphoto2 gstreamer gtk gtk2 hal imagemagick imlib java jpeg mad mmap mmx mng motif mp3 mpeg mpi ncurses nntp nptl nsplugin ogg oggvorbis opengl pcmcia perl pic png python qt quicktime readline ruby sse sse2 ssl svg tcpd threads tiff truetype usb vcd vorbis wifi win32codecs xml xml2 xv xvid zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LINGUAS
disabling PIC on x86 just avoids the issue
xine-lib is maintained under amd64, so this is job for x86 arch team. Disabling -fPIC is a no-go. For me a GCC4 issue without solution provided is a low-priority issue generally, but if someone finds a solution (a part disabling -fPIC or enabling extra CFLAGS as it was done before the noextraflags patch that allows to avoid crashes here and there) I'll be happy to apply it.
no problem, that's what i expected. just wanted to get this on file.
Debian has a patch for this problem, as well as some others. Its late though, so I'll test it out tomorrow. A quick look makes it seem like the ffmpeg they are using is a bit newer. We might only need the one asm fix. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=319563
Created attachment 67837 [details, diff] xine-lib-1.1.0-mmx-pic-regalloc.diff I've got a different, less intrusive solution. To quote myself: -- I'm wondering if ffmpeg might be better of using the gcc mmx intrinsics, since it might do better register allocation and scheduling, especially with this kind of function inlining. It would also permanently solve the problems with register allocation. Since eight different memory positions needs to be accessible from that one big MMX block he needs to put everything he needs into the normal index registers first since he can't put any register loads between the asm statements. If you don't have %ebx (-fPIC) the compiler is screwed. Well, since the code doesn't use any gcc mmx intrinsics, gcc won't touch the mmx registers and so it should be safe to assume nobody will touch these registers between to asm blocks, but gcc can insert new loads to index registers.
The change to the asm in the patch from Debian looks similar to what was done at another point in that file. I'll admit I know little, but here's the other change in ffmpeg's CVS: http://tinyurl.com/ctxuv I'm not certain which is better, but keeping it in 1 asm block instead of breaking it up seems to make more sense.
FWIW, xine-lib-1.1.0-r4 has an ffmpeg useflag that makes it use external ffmpeg, it could be useful for who wants to use gcc4.
(In reply to comment #8) > FWIW, xine-lib-1.1.0-r4 has an ffmpeg useflag that makes it use external > ffmpeg, it could be useful for who wants to use gcc4. > Not going to be useful in this case, as the newer ffmpegs aren't patched for this problem yet. (aka, we are going to need to add this patch to there as well then) I'll post my patch later. I just ripped out the one portion of the Debian patch to use, and its been working fine for me. (Watched a bunch of videos and DVDs last night with it)
Luca, ffmpeg is your package, can you take a look at this, too?
Created attachment 67947 [details, diff] GCC4 asm fix Here's the patch I'm using.
Is the latest ffmpeg showing the same issue as the internal one?
Created attachment 67980 [details, diff] simplified version of pic+fp mmx asm fix I really don't like the push/pop instructions there. We should use =&r for the clobbered registers (0 and 2). gcc will then simply reload dst and src from the stack the second time it's used which is cheaper than the push/pop combinations. Modified version of the above patch.
Created attachment 67981 [details, diff] simplified version of pic+fp mmx asm fix (really this time) Sorry, got the register indexes messed up, this one is correct.
(In reply to comment #12) > Is the latest ffmpeg showing the same issue as the internal one? No actually, media-video/ffmpeg-0.4.9_p20050906, merged fine for me.
Commited.
We are going to need this patch
*** Bug 116547 has been marked as a duplicate of this bug. ***
Luca can you push this upstream? I'd rather see it handled there than locally on Gentoo, although I'm probably going to add it to the new patchset if that's needed.
Few notes: gcc intrinsics for mmx are provent to produce bogus code at best. gcc 4.0 has been proven to pessimize the x86 code in certain situations bugs had been filled about that. Some issue could be fixed changing the code to be more gcc4 friendly but upstream is unlikely to do that right now since it could break on previous/ancient gcc versions
(In reply to comment #20) > Few notes: > > gcc intrinsics for mmx are provent to produce bogus code at best. > > gcc 4.0 has been proven to pessimize the x86 code in certain situations Not sure what you mean here. > > bugs had been filled about that. Some issue could be fixed changing the code to > be more gcc4 friendly but upstream is unlikely to do that right now since it > could break on previous/ancient gcc versions > Well, we are going to have gcc-4 in ~arch pretty soon, so this needs to be fixed.
upstream bug report: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13850 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
and halcy0n has already pushed this up to ffmpeg. http://sourceforge.net/tracker/index.php?func=detail&aid=1286673&group_id=16082&atid=116082 they don't seem to care. one response to another gcc4 compile problem was essentially "make sure you also have gcc 3.4 installed". =/
since the current gcc4 issues are regressions, makes sense to ask for fixes for it instead of adding workarounds =/
They are not regressions. This is not a problem with GCC but a problem with the inline asm.
ffmpeg-0.4.9_p20050906 and 0.4.9_p20051120 build fine with gcc 4.0/4.1, while 0.4.9_p20051216 dies. there were no changes to dsputil_mmx.c or h264dsp_mmx.c between 11/20 and 12/16 [1][2]. are we doing something different in regards to how ffmpeg is being built, or should i start looking into other changes in that time? [1]http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/ffmpeg/libavcodec/i386/dsputil_mmx.c?cvsroot=FFMpeg [2]http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/ffmpeg/libavcodec/i386/h264dsp_mmx.c?cvsroot=FFMpeg btw, offtopic but while it's on my mind, the -frename-registers switch added by xine-lib is a bad idea with >=gcc4 (but it's not the cause of this bug). "-frename-registers Attempt to avoid false dependencies in scheduled code by making use of registers left over after register allocation. This optimization will most benefit processors with lots of registers. Depending on the debug information format adopted by the target, however, it can make debugging impossible, since variables will no longer stay in a
ffmpeg-0.4.9_p20050906 and 0.4.9_p20051120 build fine with gcc 4.0/4.1, while 0.4.9_p20051216 dies. there were no changes to dsputil_mmx.c or h264dsp_mmx.c between 11/20 and 12/16 [1][2]. are we doing something different in regards to how ffmpeg is being built, or should i start looking into other changes in that time? [1]http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/ffmpeg/libavcodec/i386/dsputil_mmx.c?cvsroot=FFMpeg [2]http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/ffmpeg/libavcodec/i386/h264dsp_mmx.c?cvsroot=FFMpeg btw, offtopic but while it's on my mind, the -frename-registers switch added by xine-lib is a bad idea with >=gcc4 (but it's not the cause of this bug). "-frename-registers Attempt to avoid false dependencies in scheduled code by making use of registers left over after register allocation. This optimization will most benefit processors with lots of registers. Depending on the debug information format adopted by the target, however, it can make debugging impossible, since variables will no longer stay in a home register. Not enabled by default at any level because it has known bugs." http://gcc.gnu.org/onlinedocs/gcc-4.0.2/gcc/Optimize-Options.html
(In reply to comment #26) > ffmpeg-0.4.9_p20050906 and 0.4.9_p20051120 build fine with gcc 4.0/4.1, while > 0.4.9_p20051216 dies. there were no changes to dsputil_mmx.c or h264dsp_mmx.c > between 11/20 and 12/16 [1][2]. are we doing something different in regards to > how ffmpeg is being built, or should i start looking into other changes in that > time? The difference is now we are forcing -fPIC and such on it.
tested the asm fix, doesn't work with the default cflags, upstream will reject it.
Update, it works, but there are other issues of the same kind
(In reply to comment #29) > Update, it works, but there are other issues of the same kind > What issues? Are you fixing them?
*** Bug 117929 has been marked as a duplicate of this bug. ***
*** Bug 118444 has been marked as a duplicate of this bug. ***
Created attachment 76927 [details, diff] Alternative patch for dsputil_mmx.c Ok; how about this. The GENERAL_REGS error occurs because the compiler generates code to be able to refer to the four input memory operands (operands 4-7 in the original code) in the initial movd instructions. On gcc-4 I guess this uses more registers than it did on gcc-3. Since the first four operands aren't used after the initial four movd instructions, it's safe to split the asm at this point. The split is into two sets of two (it's the set of four that causes the problem); I think it's clear enough. I've looked at the generated assembly, and it seems sensible. This is enough for xine-lib I think, although it already has the other patch. Where ffmpeg is concerned, there are a host of other compilation failures. Most can be worked around by specifying '-fomit-frame-pointer', but postproc still has issues (postproc isn't built during xine-lib).
Created attachment 77067 [details, diff] Slightly better patch for dsputil_mmx.c (ffmpeg) Splitting the four movd's into 3 and 1 instead of 2+2 saves an lea instruction so this patch is the best so far.
Created attachment 77071 [details, diff] Ebuild patchup for x86 The static build works in all cases, so doesn't need any flag fiddling. This patch moves the flag fiddling so that it's only done for the shared build, and only on x86. I left the 'replace-flags -O0 -O2' in place, but moved the filtering of '-fforce-addr' and '-momit-leaf-frame-pointer' to the x86-only section, which now also appends -fomit-frame-pointer (similar to what xine-lib does). I don't have an amd64 to test on so I don't know whether this is ok for amd64 or not. With this, ffmpeg builds fine for me on gcc-3.4.4 and gcc-3.4.5 vanilla. To build on gcc-4.0.2 vanilla, the dsputil_mmx.c patch is also required (for the shared build only). The dsputil_mmx.c patch does cause the code for gcc-3.4.x to include the extra leal instruction, but this is such a tiny impact I don't think it's worth worrying about, so here I've applied the patch to the shared build regardless of gcc version.
*** Bug 119726 has been marked as a duplicate of this bug. ***
*** Bug 119716 has been marked as a duplicate of this bug. ***
WFM
Patch committed
*** Bug 121619 has been marked as a duplicate of this bug. ***
I'm getting this problem on my stable x86 system with ffmpeg-0.4.9_p20051216 and gcc-4.1.1. What are we supposed to do here, unmask ffmpeg? Can a newer ffmpeg be marked stable, or can the patch work with the stable version of ffmpeg? Portage 2.1-r2 (default-linux/x86/2006.1/desktop, gcc-4.1.1, glibc-2.4-r3, 2.6.16-gentoo-r9 i686) ================================================================= System uname: 2.6.16-gentoo-r9 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz Gentoo Base System version 1.12.4 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [enabled] app-admin/eselect-compiler: [Not Present] dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.3 dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O -march=pentium4 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config /var/bind" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O -march=pentium4 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks fixpackages metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.mirrors.easynews.com/linux/gentoo http://mirror.datapipe.net/gentoo http://gentoo.osuosl.org" LANG="en_US.utf8" LC_ALL="en_US.utf8" LINGUAS="en" MAKEOPTS="-j2" 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'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" USE="x86 X audiofile avi bash-completion berkdb bitmap-fonts bzip2 cairo cdr cli crypt curl dbus dlloader dri dvd dvdr encode exif fam ffmpeg firefox flac fortran freetype gdbm gif gnutls gpm gtk hal howl idn ipv6 isdnlog java jpeg jpeg2k kde kdeenablefinal lcms libg++ lm_sensors logrotate mad mmx mng mp3 mpeg musicbrainz ncurses nls nptl nptlonly offensive ogg opengl pam pcre pdflib perl png ppds pppd python qt3 qt4 quicktime readline reflection ruby session spell sse sse2 ssl threads tiff truetype truetype-fonts type1-fonts udev unicode usb vorbis win32codecs xml xorg xv zeroconf zlib elibc_glibc input_devices_keyboard input_devices_mouse input_devices_evdev kernel_linux linguas_en userland_GNU video_cards_nvidia" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Question: this bug is RESOLVED, however GCC-4.x is still masked in hardened, referring to this bug... /usr/portage/profiles/hardened/package.mask