Compiler output: i686-pc-linux-gnu-gcc -Wall -Wno-switch -O2 -fomit-frame-pointer -fomit-frame-pointer -DHAVE_AV_CONFIG_H -I.. -I/var/tmp/portage/ffmpeg-0.4.9_p20060530/work/ffmpeg-0.4.9-p20060530-shared/libavutil -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE -fPIC -DPIC -c -o i386/snowdsp_mmx.o i386/snowdsp_mmx.c i386/snowdsp_mmx.c: In function 'ff_snow_vertical_compose97i_sse2': i386/snowdsp_mmx.c:461: error: PIC register '%ebx' clobbered in 'asm' i386/snowdsp_mmx.c: In function 'ff_snow_vertical_compose97i_mmx': i386/snowdsp_mmx.c:568: error: PIC register '%ebx' clobbered in 'asm' i386/snowdsp_mmx.c: In function 'inner_add_yblock_bw_8_obmc_16_mmx': i386/snowdsp_mmx.c:869: error: PIC register '%ebx' clobbered in 'asm' make[1]: *** [i386/snowdsp_mmx.o] Error 1 make[1]: Leaving directory `/var/tmp/portage/ffmpeg-0.4.9_p20060530/work/ffmpeg-0.4.9-p20060530-shared/libavcodec' make: *** [lib] Error 2 localhost old # emerge --info Portage 2.1.1_pre4-r1 (default-linux/x86/2006.0, gcc-4.1.1/vanilla, glibc-2.4-r3, 2.6.17-gentoo-r4 i686) ================================================================= System uname: 2.6.17-gentoo-r4 i686 Intel(R) Pentium(R) M processor 2.00GHz Gentoo Base System version 1.12.1 app-admin/eselect-compiler: 2.0.0_rc2-r1 dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.60 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.17 sys-devel/gcc-config: 2.0.0_rc1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2" 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" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/eselect/compiler /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-O2" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" 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" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X aac alsa apache2 apm arts avi berkdb bitmap-fonts cdr cli crypt cups dlloader dri dvb dvd dvdr eds emboss encode esd exif foomaticdb fortran gdbm gif gpm gstreamer gtk2 i810 imlib ipv6 isdnlog jpeg kde kdeenablefinal libg++ libwww mad mikmod mmx motif mp3 mpeg mysql ncurses nls nptl nptlonly nsplugin ogg opengl oss pam pcre pdflib perl png pppd python qt qt3 qt4 quicktime readline reflection sdl session spell spl sse sse2 ssl tcpd truetype truetype-fonts type1-fonts udev vorbis win32codecs xml xmms xorg xv xvid zlib elibc_glibc input_devices_keyboard input_devices_mouse input_devices_evdev kernel_linux userland_GNU video_cards_i810" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Same here. Portage 2.1.1_pre4-r1 (default-linux/x86/2006.0, gcc-4.1.1/vanilla, glibc-2.4-r3 , 2.6.17-gentoo-r4 i686) ================================================================= System uname: 2.6.17-gentoo-r4 i686 AMD Athlon(tm) XP 3200+ Gentoo Base System version 1.12.1 ccache version 2.4 [enabled] app-admin/eselect-compiler: 2.0.0_rc2-r1 dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r2 dev-util/confcache: 0.4.2-r1 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.60 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.17 sys-devel/gcc-config: [Not Present] sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shu tdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/eselect/compiler /etc/gcon f /etc/java-config/vms/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf /web2c" CXXFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks metadata-transfer parallel-fetch sandbox s fperms strict" GENTOO_MIRRORS="ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://distf iles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" LANG="de_DE@euro" LC_ALL="de_DE@euro" LINGUAS="de" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from=/etc/portage/rsync_excludes" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/d istfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/portage/local/layman/vmware" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowext X a52 aac acpi alsa apache2 apm arts avi bash-completion berkdb bitmap-fonts bluetooth bzip2 cairo cdparanoia cli crypt css cups curl db us dlloader dvd dvdr dvdread emboss ffmpeg firefox foomaticdb fortran gdbm gtk2 hal hbci howl isdnlog jpeg kde kdeenablefinal kdehiddenvisibility libg++ libwww lm_sensors mad mmx mmxext mozcalendar mozsvg mp3 mpeg mplayer musicbrainz ncurse s nls nptl nsplugin nvidia ogg opengl pam pcre pdf pdflib perl pic png pppd prof ile python qt qt3 quicktime readline real reflection samba session slang slp spe ll spl sse ssl svg tcpd threads truetype truetype-fonts type1-fonts udev vorbis win32codecs x264 xml xorg xv xvid xvmc zlib elibc_glibc input_devices_keyboard i nput_devices_evdev kernel_linux linguas_de userland_GNU video_cards_none video_c ards_nvidia video_cards_nv" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, MAKEOPTS
*** Bug 142385 has been marked as a duplicate of this bug. ***
USE=-mmx makes things work. This looks like a gcc-4.1.1 issue to me.
I use gcc 3.4.6 and have the same problem.
Same problem.. i686-pc-linux-gnu-gcc -Wall -Wno-switch -O2 -march=athlon-xp -pipe -g -fomit-frame-pointer -fomit-frame-pointer -DHAVE_AV_CONFIG_H -I.. -I/var/tmp/portage/ffmpeg-0.4.9_p20060530/work/ffmpeg-0.4.9-p20060530-shared/libavutil -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE -fPIC -DPIC -c -o i386/snowdsp_mmx.o i386/snowdsp_mmx.c i386/snowdsp_mmx.c: In function 'ff_snow_vertical_compose97i_sse2': i386/snowdsp_mmx.c:461: error: PIC register '%ebx' clobbered in 'asm' i386/snowdsp_mmx.c: In function 'ff_snow_vertical_compose97i_mmx': i386/snowdsp_mmx.c:568: error: PIC register '%ebx' clobbered in 'asm' i386/snowdsp_mmx.c: In function 'inner_add_yblock_bw_8_obmc_16_mmx': i386/snowdsp_mmx.c:869: error: PIC register '%ebx' clobbered in 'asm' make[1]: *** [i386/snowdsp_mmx.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make[1]: Leaving directory `/var/tmp/portage/ffmpeg-0.4.9_p20060530/work/ffmpeg-0.4.9-p20060530-shared/libavcodec' make: *** [lib] Error 2 Using.. CFLAGS="-O2 -march=athlon-xp -pipe -g" CXXFLAGS="${CFLAGS}"
See Bug #136171 Workaround: Disable the mmx useflag
*** Bug 136171 has been marked as a duplicate of this bug. ***
Same here, using GCC 4.1.1.
The same here
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-April/010304.html
I believe comment #10 is wrong. I have (and others) fomit-frame-pointer in CFLAGS and still recieve the error. Also, looking at the original bug reporter's comment: i686-pc-linux-gnu-gcc -Wall -Wno-switch -O2 -fomit-frame-pointer <----
yeah my bad.. i realized that just after i pushed the commit button i should have tested that first. It doesn't work anyways :)
Anyways, their mailing list mentions this bug here: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-April/010294.html and here: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-March/009600.html With a proposed fix here: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-March/008506.html The proposed fix has very long discussion btw.
Reassigning this to the x86 team since this an x86 specific problem.
*** Bug 142463 has been marked as a duplicate of this bug. ***
Same problem here & works fine without the MMX flag set. i386/fft_3dn2.c: In function 'ff_fft_calc_3dn2': i386/fft_3dn2.c:44: warning: implicit declaration of function '_m_femms' i386/fft_3dn2.c:47: error: '__m64' undeclared (first use in this function) i386/fft_3dn2.c:47: error: (Each undeclared identifier is reported only once i386/fft_3dn2.c:47: error: for each function it appears in.) i386/fft_3dn2.c:47: error: 'r' undeclared (first use in this function) i386/fft_3dn2.c:47: error: 'a0' undeclared (first use in this function) i386/fft_3dn2.c:47: warning: left-hand operand of comma expression has no effect i386/fft_3dn2.c:47: error: 'a1' undeclared (first use in this function) i386/fft_3dn2.c:47: warning: left-hand operand of comma expression has no effect i386/fft_3dn2.c:47: error: 'b0' undeclared (first use in this function) i386/fft_3dn2.c:47: warning: left-hand operand of comma expression has no effect i386/fft_3dn2.c:47: error: 'b1' undeclared (first use in this function) i386/fft_3dn2.c:47: warning: left-hand operand of comma expression has no effect i386/fft_3dn2.c:47: error: 'c' undeclared (first use in this function) i386/fft_3dn2.c:47: warning: left-hand operand of comma expression has no effect i386/fft_3dn2.c:47: warning: statement with no effect i386/fft_3dn2.c:49: error: expected expression before ')' token i386/fft_3dn2.c:51: error: expected expression before ')' token i386/fft_3dn2.c:53: error: expected expression before ')' token i386/fft_3dn2.c:58: warning: implicit declaration of function '_m_pfadd' i386/fft_3dn2.c:59: warning: implicit declaration of function '_m_pfsub' i386/fft_3dn2.c:66: warning: implicit declaration of function '_m_pswapd' i386/fft_3dn2.c:67: warning: implicit declaration of function '_m_pxor' i386/fft_3dn2.c:91: error: expected ';' before 'a0' i386/fft_3dn2.c:93: error: expected expression before ')' token i386/fft_3dn2.c:94: error: expected expression before ')' token i386/fft_3dn2.c:95: error: expected expression before ')' token i386/fft_3dn2.c:96: error: expected expression before ')' token i386/fft_3dn2.c:99: error: 'c0' undeclared (first use in this function) i386/fft_3dn2.c:99: error: expected expression before ')' token i386/fft_3dn2.c:100: error: 'c1' undeclared (first use in this function) i386/fft_3dn2.c:100: error: expected expression before ')' token i386/fft_3dn2.c:102: error: 't10' undeclared (first use in this function) i386/fft_3dn2.c:102: warning: implicit declaration of function '_m_pfmul' i386/fft_3dn2.c:103: error: 't11' undeclared (first use in this function) i386/fft_3dn2.c:108: error: 't20' undeclared (first use in this function) i386/fft_3dn2.c:109: error: 't21' undeclared (first use in this function) i386/fft_3dn2.c:112: warning: implicit declaration of function '_m_pfpnacc' i386/fft_3dn2.c:116: error: expected expression before ')' token i386/fft_3dn2.c:117: error: expected expression before ')' token i386/fft_3dn2.c:118: error: expected expression before ')' token i386/fft_3dn2.c:119: error: expected expression before ')' token make[1]: *** [i386/fft_3dn2.o] Error 1 make[1]: Leaving directory `/var/tmp/portage/ffmpeg-0.4.9_p20060530/work/ffmpeg-0.4.9-p20060530-static/libavcodec' make: *** [lib] Error 2 For both cases (working and not working), my flags in make.conf are ... CFLAGS="-march=pentium4m -O2 -fomit-frame-pointer -pipe -mmmx -msse -msse2 -mno-sse3 -mno-3dnow" CXXFLAGS="${CFLAGS}"
Sorry but a) I don't take care of ffmpeg myself directly; b) x86 problems goes to x86 arch team, exactly as if it was VIS failing it'd be sent to SPARC team.
(In reply to comment #13) > With a proposed fix here: > http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-March/008506.html > The proposed fix has very long discussion btw. I don't think this is a proposed fix, I believe this is the patch that caused this bug in the first place. From the discussion, perhaps this lead you to think it's a fix. http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-March/008613.html: >> a minor issue, dont use ebx please, it causes PIC fanboys to flame us >> and a major one REG_c is changed and not an output or cloberlisted >> > ebx changed to REG_b. h_b (input to the function) has been changed from > type int to type long so that this fix will work. But REG_b is #defined to ebx, so this changes nothing.
do you guys use the -fPIC CFLAG? I was thinking it might be the problem, filtering it out has helped other packages
(In reply to comment #2) > *** Bug 142385 has been marked as a duplicate of this bug. *** In the above bug report I wrote: > This is a known bug: > http://article.gmane.org/gmane.comp.video.ffmpeg.devel/31520 > Removing -fPIC reports to fix this problem, though I did not test that.
I can confirm that -fPIC causes the error, emerge without it just runs fine. Portage 2.1-r1 (default-linux/x86/2006.0, gcc-3.4.6, glibc-2.3.6-r4, 2.6.17-gentoo-r4 i686) ================================================================= System uname: 2.6.17-gentoo-r4 i686 AMD Athlon(tm) XP 2500+ Gentoo Base System version 1.6.15 app-admin/eselect-compiler: [Not Present] dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] 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="-O2" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/splash /etc/terminfo" CXXFLAGS="-O2" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache collision-protect distlocks metadata-transfer parallel-fetch sandbox sfperms strict test" GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo/" LANG="de_DE@euro" LC_ALL="de_DE@euro" LINGUAS="de" 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.informatik.rwth-aachen.de/gentoo-portage" USE="x86 3dnow 3dnowext X Xaw3d a52 alsa arts artworkextra asf audiofile avi bash-completion beagle berkdb bidi bitmap-fonts bootsplash branding bzip2 cairo cdda cddb cdparanoia cdr cli cracklib crypt css cups curl custom-cflags dbus dga directfb divx4linux dlloader dri dts dvd dvdr dvdread dvi eds emacs emboss encode esd evo exif expat fam fat fbcon fdftk ffmpeg firefox foomaticdb fortran ftp gb gcj gdbm gif gnome gpm gstreamer gtk gtk2 gtkhtml hal icq idn imagemagick imap imlib ipv6 isdnlog java javascript jikes jpeg jpeg2k ldap leim libg++ libwww lm_sensors mad maildir matroska mbox mikmod mime mmx mmxext mng mono motif mp3 mpeg mpeg2 mule nautilus ncurses nforce2 nls nocardbus nptl nptlonly nsplugin nvidia objc ogg opengl pam pcre pdf pdflib perl plotutils pmu png ppds pppd preview-latex print python qt qt3 qt4 quicktime readline reflection reiserfs samba sdk session slang spell spl sse ssl svg svga t1lib tcltk tcpd theora thunderbird tiff truetype truetype-fonts type1-fonts udev usb vcd videos vorbis win32codecs wmf wxwindows xine xml xorg xosd xv xvid zlib elibc_glibc input_devices_mouse input_devices_keyboard kernel_linux linguas_de userland_GNU video_cards_radeon video_cards_vesa video_cards_fbdev" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
(In reply to comment #20) > > This is a known bug: > > http://article.gmane.org/gmane.comp.video.ffmpeg.devel/31520 > > Removing -fPIC reports to fix this problem, though I did not test that. Commenting out the PIC-related lines from the ebuild fixed the problem for me. Perhaps a pic USE flag for x86 (or all) users should be added?
Created attachment 93285 [details, diff] Patch snowdsp_mmx.c to avoid or restore ebx Since there is so much activity on this bug here, I tried to get this fixed. Don't know too much about video editing or inline assembly, but I think this might work. I tried to use another register instead of ebx whenever possible. In cases where all 6 general purpose and index registers are used, I allocated a local variable and stored ebx there for the time being. Using a local variable avoids worrying about changing esp and makes sure all input arguments are still valid. Maybe someone who knows what this piece of code is actually for could give it a try if it still does what you'd expect it to do?
*** Bug 142641 has been marked as a duplicate of this bug. ***
(In reply to comment #23) > Created an attachment (id=93285) [edit] > Patch snowdsp_mmx.c to avoid or restore ebx > > Maybe someone who knows what this piece of code is actually for could give it a > try if it still does what you'd expect it to do? The patch applies, and ffmpeg now compiles and runs with -fPIC here. Unfortunately, that's about all I can tell you. I don't use ffmpeg often. However, while reading up on the compile error, I stumbled upon something interesting. http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-March/009613.html "That looks like my code. If PIC support is very important to anyone (whatever that is), they're free to write a patch that avoids the use of ebx. Avoiding it is easy in vertical_compose, but it will likely be very hard to avoid using in inner_add_yblock because every register gets used, and I already had to make sacrifices to squeeze it in the existing registers. A loss of speed in add_yblock is also inevitable if ebx is not used (perhaps as little as a push and pop of ebx if you can use that with GCC inline assmebly)." I'm not a programmer, but your patch seems to do just that, i.e. not using the ebx registers. Is there another way to do this?
(In reply to comment #25) > I'm not a programmer, but your patch seems to do just that, i.e. not using the > ebx registers. Yes, I read that message as well. In some cases that's what I did, and in others I restored the old value of ebx so it isn't clobbered after the asm block. > Is there another way to do this? Probably yes: 1. Use push/pop - might break stack relative addressing of parameters ? 2. Use some register freed by -fomit-frame-pointer - don't know how, though 3. Rewrite asm code to use fewer registers - would require more understanding 4. Convince gcc to manage ebx - don't know how, as simply adding -fcall-saved-ebx to CFLAGS does not work. 5. Improve gcc to take care of ebx - should work unless parameters are ebx-relative, but to my knowledge it has not been implemented so far. So there are likely to be other approaches to the problem, and I don't claim mine to be the best. I submitted my patch to the ffmpeg-devel list, but as I'm not a list member it seems it has not been forwarded yet. Any ffmpeg-devel members here? To get the thing included upstream it would likely need to be "#ifdef PIC"ed so that non-PIC code suffers no penalty at all. I'm waiting for someone to confirm that the code still works before doing further work in that direction. For Gentoo it should be enough to apply the patch to the shared source tree only.
(In reply to comment #26) For > Gentoo it should be enough to apply the patch to the shared source tree only. > Martin, thank you for the patch. From looking over it it should work. I'll have to test it later tonight before bumping up the version with permission from the video herd. Really, this is as much a hardened thing as a x86 specific one but *shrugs* as long as it gets fixed.
I've been hit by this bug as well (x86, gcc-4.1.1), but the patch from comment #23 worked very well. I've searched a bit and I've found that this is not the first time a package suffers from similar problems, just to recap: * Bug #73342 where xine-lib-1-rc7 gets a fix for clobbering %ebx * Posts from mplayer developers (especially the second one), where problems regarding SSE optimizations are discussed: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-March/008506.html http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-March/009613.html * Bug #86843 where interdependencies between USE=mmx, CFLAGS=-fPIC, -DPIC define and shortage of registers on x86 are discussed Overall, it's been an interesting learning experience. And the patch from comment #23: http://bugs.gentoo.org/attachment.cgi?id=93285&action=view compared to the one from Bug #73342: http://bugs.gentoo.org/attachment.cgi?id=47148&action=view really looks good. Not to mention that it works, too :-) I hope this will make its way to the portage eventually.
*** Bug 142898 has been marked as a duplicate of this bug. ***
*** Bug 143017 has been marked as a duplicate of this bug. ***
*** Bug 143027 has been marked as a duplicate of this bug. ***
identical problem here. USE="a52 aac dts encode imlib mmx network ogg sdl theora threads truetype v4l vorbis xvid zlib -amr -debug -doc -ieee1394 -oss -test -x264" CFLAGS="-Os -pipe -march=athlon-xp -fforce-addr -fomit-frame-pointer -falign-functions=4 -mfpmath=sse"
Same bug with this : USE="acpi -apm aalib 3dnow 3dnowext mmx mmxext sse sse2 \ aac X gtk2 gnome wxwindows -qt -qt3 -qt4 -kde -arts dvd alsa cdr nptl \ nvidia cjk xinerama unicode matroska win32codecs real xvid ldap a52 ffmpeg hal theora ieee1394 dts \ -xmms -ipv6 firefox nsplugin \ bzip2 tiff lcms mng gtkhtml -apache2 hal dbus gphoto2" CFLAGS="-march=athlon-xp -O3 -pipe -mmmx -m3dnow -msse -msse2 -fomit-frame-pointer -fforce-addr -ftracer"
I'm not ignoring you, I pushed the patch upstream and I'm working with the team to have the issue fixed.
http://article.gmane.org/gmane.comp.video.ffmpeg.devel/34897 update: patch not correct.
Created attachment 93696 [details, diff] patch mmx.h to use ebp instead of ebx as REG_b in PIC mode (In reply to comment #35) > http://article.gmane.org/gmane.comp.video.ffmpeg.devel/34897 (from that message) > if REG_b is not on the clobber list then you cannot clobber it, for example > it might be used in a "m" or a "r" This argument is valid in the general case. However, if you really do use PIC mode, then you could probably rely on ebx being used for the GOT and nothing else, and thus all operands being independent from ebx because they are not GOT-relative. But I agree there are quite some ifs and a lot of dependence on current behaviour that is likely to change in some future version. So another, cleaner approach would be nice if any such is possible. I attached another solution. This time I rely on -fomit-frame-pointer, which frees ebp to be used as a sixth register. So whoever wants to use -fPIX should specify -fomit-frame-pointer as well (as the Gentoo ebuild automatically does), and my patch should hopefully handle the rest. Sources compile cleanly. I also did some basic tests to see if I could get gcc to allocate six registers by itself: http://gcc.gnu.org/bugzilla/attachment.cgi?id=12038 As you can see from the URL, things did not go as smoothly as I had hoped. Especially when combining this approach with no optimization or some other code, things did not work well. The details seem extremely bizarre to me and are documented at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28635 But with some optimization and only one asm statement per function, things seemed to work, so this might be another approach that could do without preprocessor magic. Would require some major rewriting of existing asm code, though.
We should really try to get away from relying on -fomit-frame-pointer to free up a register.
(In reply to comment #37) > We should really try to get away from relying on -fomit-frame-pointer to free > up a register. Why? Do you have any idea how to achieve this? There seems to be quite a lot of code that uses six registers. If we really can't use ebx for -fPIC, omitting frame pointers seems the only viable approach to me, short of rewriting all this code to some less performant implementation with less registers. Let me just look at this list I posted before... (In reply to comment #26) > 1. Use push/pop - might break stack relative addressing of parameters ? I verified that especially with -fomit-frame-pointer, esp is really part of most local variable addresses. Even worse, this would clobber ebx in between as well, so it's no better than my patch from comment 23. > 2. Use some register freed by -fomit-frame-pointer - don't know how, though That's my new patch from comment 36, of course depending on this flag. > 3. Rewrite asm code to use fewer registers - would require more understanding The only viable solution I see for not relying on -fomit-frame-pointer and still using -fPIC. I fear it will have a performance impact. > 4. Convince gcc to manage ebx - don't know how, as > simply adding -fcall-saved-ebx to CFLAGS does not work. Still no idea here. I fear it might simply not be possible. > 5. Improve gcc to take care of ebx - should work unless parameters are > ebx-relative, but to my knowledge it has not been implemented so far. This still has some appeal to me, but it might prove extremely difficult. Basically gcc would take care of saving and restoring ebx as well as ensuring that no other parameter relies on ebx. But I fear even if we could get gcc to do this, it would not be an option for upstream, as it would make ffmpeg rely on a patched and/or very recent gcc, which probably is unacceptable there. For those interested, http://gcc.gnu.org/viewcvs/trunk/gcc/stmt.c contains the code leading to this message in expand_asm_operands. It would need some way to notice if any of the operands uses ebx, and should only fail if this is the case as well as ebx being in the clobber list. Anyone here knows more about gcc?
*** Bug 143187 has been marked as a duplicate of this bug. ***
It seems the other patch got rejected as well, may be just add a pic use flag and warn people that some things might break?
the proposed solution got reject, please make sure that it passes make test or it will be rejected by default.
After 7 days, I start to think a temp fix should be applied ASAP aka: remove -fPIC for x86 until a patch get accepted upstream... Don't tell me it's bad... it's obviously not possible to compile this thing on x86 without a clean patch that don't exist yet (and it seems it won't be that easy to produce). Btw, plz, don't start to argue it's against some rules, on x86 it's a fake issue...
Pierre, a simpler solution that can already be put in place by the users without having to modify the ebuild, it to turn off the mmx USE flag. This can be done for ffmpeg only as follows: Edit /etc/portage/package.use Add a line that reads: media-video/ffmpeg -mmx Once this bug is marked as fixed, you can simply remove the line from /etc/portage/package.use. This should solve your problem immediately... 5:)
(In reply to comment #43) > Pierre, a simpler solution that can already be put in place by the users > without having to modify the ebuild, it to turn off the mmx USE flag. Mike, the simplest solution for right now, would be to simply dump the mmx USE flag and then later re-add it, if a fix is found. I can't understand, why Gentoo knowingly ships something, which does not work. Beats me.
(In reply to comment #44) > (In reply to comment #43) > > Pierre, a simpler solution that can already be put in place by the users > > without having to modify the ebuild, it to turn off the mmx USE flag. > > Mike, the simplest solution for right now, would be to simply dump the mmx USE > flag and then later re-add it, if a fix is found. I can't understand, why > Gentoo knowingly ships something, which does not work. Beats me. > This one got my ire up a bit, thanks kindly. I didn't run into this bug as I don't run mmx as a flag. Testing for ~arch, which is not the stable tree, I wouldn't of considered actually looking that closely. It worked for me without issue. However, we have lots of users who run with mmx in their use flags..that's a choice that I didn't make. Saying that we shipped it knowing it was broken is stepping over the bounds and I'm quite disappointed in your response because of it. It does work, it just isn't perfect. Thats different from what you say is just plain broken. We have a place for things that are entirely broken and its called package.mask. ~arch is not stable. So please don't expect it to always work. I'm seriously going to have to start a campaign that ~arch isn't stable. Use it at your own risk. Tsunam, the one one who did the ~arch commit, has tested this with issues and has personally looked into ways of fixing it, but nope..doesn't matter as its just plain broken entirely *nods*. Thanks for making me love the people I consider peers that much more!
*** Bug 143281 has been marked as a duplicate of this bug. ***
(In reply to comment #16) > Same problem here & works fine without the MMX flag set. Same here.
(In reply to comment #45) > (In reply to comment #44) > > Mike, the simplest solution for right now, would be to simply dump the mmx USE > > flag and then later re-add it, if a fix is found. I can't understand, why > > Gentoo knowingly ships something, which does not work. Beats me. > > > > > This one got my ire up a bit, thanks kindly. I didn't run into this bug as I > don't run mmx as a flag. Fine. Not much of a problem. > Testing for ~arch, which is not the stable tree, I > wouldn't of considered actually looking that closely. Fine. > It worked for me without > issue. As you don't have mmx in your USE flags. > However, we have lots of users who run with mmx in their use > flags..that's a choice that I didn't make. Fine. > Saying that we shipped it knowing it was broken is stepping over the bounds and > I'm quite disappointed I'm also quite disappointed by Gentoo still offering this version with MMX support. Why not simply release a -r1, where MMX flag is not supported? > in your response because of it. It does work, it just > isn't perfect. Where does the current version work on x86 (ie. the x86 hardware, not the x86 arch in Gentoo speak) with MMX? > Thats different from what you say is just plain broken. Where did I say, that it's *plain* broken (or "entirely", as you later say)? > We have > a place for things that are entirely broken and its called package.mask. ~arch > is not stable. So please don't expect it to always work. I don't. But I don't expect it to KNOWLINGY for a rather long period of time to NOT work, which is the current state of ffmpeg with regards to MMX support or the mmx USE flag. > Tsunam, the one one who did the ~arch commit, has tested this with issues and > has personally looked into ways of fixing it, but nope..doesn't matter as its > just plain broken entirely I did not say, that it's entirely broken. I said, that the MMX flag should be dropped, as this is broken - else, there wouldn't be this bug, would there? I further said, that the mmx flag should be re-added, as soon as MMX is working again.
Hey guys. Please keep the arguments down on the bugzilla. That's what the mailing lists are for. Anyways, if you drop the useflag, a revbump should not be nessary because that's what newuse is for (and the new portage version will pick it up as well).
Calm down, ladies. Which part of "unstable" is it you don't understand?
(In reply to comment #41) > the proposed solution got reject, please make sure that it passes make test or > it will be rejected by default. OK, I finally subscribed to the mailing lists, and got myself a svn checkout so I'm working on a clean source tree and have all those tests at hand. I'm also finally sitting in front of the machine I'm testing things on, and I'm heading for a major rewrite. I'll take my patches upstream myself from now on. I just got somewhat confused from these lines in the ebuild: > #disable mmx accelerated code if not requested, or if PIC is required > # as the provided asm decidedly is not PIC. > if ( gcc-specs-pie || ! use mmx ) && ( ! use amd64 ); then > myconf="${myconf} --disable-mmx" > fi I take it they are talking about PIE, because PIC libraries did work in previous versions afaik.
Created attachment 93868 [details, diff] ebuild patch to remove PIC for the special case of MMX+x86 Ok, my previous post was not intended to generate so much noise... I won't feed the troll even if I really want to... Just to make things clear: It was not an remark against devs... just against some "politics" issue... I include an unholy patch to the ebuild to AT LEAST compile this package WITH MMX [This has performance inpact] and without PIC (on x86 only... where position indep. code has the advantage to not be usefull) Cheers,
(In reply to comment #52) > Created an attachment (id=93868) [edit] > ebuild patch to remove PIC for the special case of MMX+x86 This will not work on amd64, libraries have to be PIC on amd64 to link. But anyway we have more registers on amd64 so we only need to pick a free register to use.
(In reply to comment #52) > Created an attachment (id=93868) [edit] > ebuild patch to remove PIC for the special case of MMX+x86 > > Ok, my previous post was not intended to generate so much noise... I won't feed > the troll even if I really want to... Just to make things clear: It was not an > remark against devs... just against some "politics" issue... > > I include an unholy patch to the ebuild to AT LEAST compile this package WITH > MMX [This has performance inpact] and without PIC (on x86 only... where > position indep. code has the advantage to not be usefull) > > Cheers, > This kills hardened support for the package, and althought it'd fix it, its not ideal either. We are working on the issue, and attempting to get a proper fix that doesn't affect anyone negatively. For now the fix is either to not run the 530 build, as other versions work with mmx and pic, or remove mmx from this one ebuild.
(In reply to comment #53) > (In reply to comment #52) > > Created an attachment (id=93868) [edit] > > ebuild patch to remove PIC for the special case of MMX+x86 > > This will not work on amd64, libraries have to be PIC on amd64 to link. > > But anyway we have more registers on amd64 so we only need to pick a free > register to use. > Sorry, it is working on amd64 as it is now....
I guess the line "if [[ $(tc-arch) == "x86" ]]; then" in the patch I sended should avoid to apply it on amd64 no ? Anyway, I posted the patch since it's the way I used to fix the prob on my side, for the people who still want to keep MMX :-)
Created attachment 93918 [details, diff] Patch to snowdsp_mmx.c This patch has been accepted and included upstream: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-August/013818.html I just checked that an ebuild applying this patch compiles on my system. I would like to see an ebuild applying this patch or using a recent snapshot in portage asap, as the number of cc list members indicates a lot of interest.
I'd rather wait for a day till the vorbis optimization are checked in.
*** Bug 143864 has been marked as a duplicate of this bug. ***
Created attachment 94217 [details] Ebuild with patch for snowdsp_mmx While Luca is for the Vorbis optimizations to be checked in... To save anbody else having to to this make this just to get their update to finish cleanly: Here is a complete ebuild ready to be untared in the root of your favourite overlay (it includes the media-video/ffmpeg/ tree). This '-r1' version will no doubt clash with Luca's next update so be warned Be prepared to delete it from your overlay and force ffmpeg to update (emerge -av --oneshot ffmpeg) to get Luca's real '-r1' version.
(In reply to comment #60) Nice thing, but there are minor issues to remember for the future. > Ebuild with patch for snowdsp_mmx I'd not call this an ebuild, as it is a tar archive containing additional files as well. Seeing an attachmend called ebuild, I'd expect just a single text/plain file, the ebuild itself. > This '-r1' version will no doubt clash with Luca's next update so be warned > Be prepared to delete it from your overlay and force ffmpeg to update (emerge > -av --oneshot ffmpeg) to get Luca's real '-r1' version. I don't think it will clash. I guess the p2006... part of the version is in fact the CVS snapshot date, so that the next version will probably be based on an altogether new snapshot. Still, why did you name your ebuild -r1? The issue is a compile time issue, so people either had things working (because of no mmx or some such) or are still stuck with some older version. OK, they might have an entry in their package.use that says "=media-video/ffmpeg-0.4.9_p20060530 -mmx", but people who explicitly download your overlay fragment will manage to remove this setting and remerge the package as well, especially as you already gave the command for this. My point is: in my understanding revisions are for automatic updates leading to improvements to the runtime behaviour. Compile time issues should not need revision bumps, and ebuilds from your private overlay neither. I'd just call this ffmpeg-0.4.9_p20060530, and let the overlay take precedence over the main portage tree as it does by default.
Martin since ffmpeg is going to depend on an x264 version that's too new for other software (and I learned that the hard way) I'll commit your patch in a ffmpeg bug and I'll add the new snapshot in p.mask . Thank you for your contribution =)
Comment on attachment 94217 [details] Ebuild with patch for snowdsp_mmx Ops. I didn't notice it was a compressed file, please, next time attach just the ebuild
ebuild updated, wait an hour and then try to emerge it
Now it works here, same setup. Thanks for your great work!
closing as fixed as well now
