gcc -march=athlon-xp -O3 -pipe -I. -c -fPIC -DPIC ./jdapimin.c jdapimin.c: In function `mmxsupport': jdapimin.c:463: internal compiler error: asm clobber conflict with output operand Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://bugs.gentoo.org/> for instructions. make: *** [jdapimin.lo] Error 1 !!! ERROR: media-libs/jpeg-mmx-1.1.2-r1 failed. !!! Function src_compile, Line 29, Exitcode 2 !!! make failed This happened first on the Pentium M notebook I'm building, with -O3 - lowering to -O2 did not correct the problem (as has helped with some other GCC 3.3 problems). I tried also on my desktop Athlon XP system: same error. This does not happen with 3.2.3.
I have just confirmed this bug to be unrelated to the hammer patch. I tried compiling this with an unpatched version of gcc 3.3, and got the same error: ./libtool --mode=compile gcc -march=pentium4 -msse -msse2 -mfpmath=sse -O3 -pipe -I. -c ./jdapistd.c jdapimin.c: In function `mmxsupport': jdapimin.c:463: internal compiler error: asm clobber conflict with output operand It is also not a -O3 related bug since it happens with -O2 as well. It also has nothing to do with sse/sse2 which are available on both the P4 and athlon-xp: gcc -march=pentium4 -mno-sse -mno-sse2 -pipe -I. -c -fPIC -DPIC ./jdapimin.c jdapimin.c: In function `mmxsupport': jdapimin.c:463: internal compiler error: asm clobber conflict with output operand It also happens with march set to i686 or i383 with -march and -pipe being the only c flags. I'm going to come back to this later after doing more testing with gcc 3.3 but i must thank you greatly for filing this bug, as I seem to have accidentally skipped this package during my own attempts at bringing stuff up to date with gcc 3.3. :)
This bug is caused by -fPIC. ayanami jpeg-mmx # gcc -march=pentium4 -msse -msse2 -mfpmath=sse -O3 -pipe -fno-strict-aliasing -I. -c ./jdapimin.c ayanami jpeg-mmx # gcc -march=pentium4 -msse -msse2 -mfpmath=sse -O3 -pipe -fno-strict-aliasing -I. -c -fPIC ./jdapimin.c jdapimin.c: In function `mmxsupport': jdapimin.c:463: internal compiler error: asm clobber conflict with output operand Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://bugs.gentoo.org/> for instructions.
Hey, hit this bug too. So far, here is what i know: There is a conflict in the list of registers that the ASM in that function lists as clobbered, and the output operand... the output is memory though, so that didn't make alot of sense. BUT, because it goes away w/o PIC, i was thinking that PIC might need a free register (unclobbered) to calculate the memory location with... I am in the process of tinkering with the ASM, and as soon as get any results or am completely stumped i will post here again.
Ok. I have the fix, just compiled it successfully... I am going to clean it up some, and then i'll submit it here for testing while i test it some myself. -illusion (carrbc1@wfu.edu)
Created attachment 14945 [details, diff] fix for jpeg-mmx gcc33 fix This fixes up the gcc3.3 PIC bug in the assembly. Also a few cleanups for the assembly. -illusion
Created attachment 14946 [details, diff] the REAL fix... no bzip sorry... forgot it couldn't be bzipped
Does anyone know what happened to upstream jpeg-mmx? On the sourceforge-page, there is only a version 0.1.4. Is this newer than the 1.1.2 found in gentoo?
Note: this bug still exists in gcc 3.3.1 :( ./libtool --mode=compile gcc -march=pentium4 -O2 -pipe -I. -c ./jdapistd.c gcc -march=pentium4 -O2 -pipe -I. -c -fPIC -DPIC ./jdapimin.c jdapimin.c: In function `mmxsupport': jdapimin.c:463: internal compiler error: asm clobber conflict with output operand Please submit a full bug report, with preprocessed source if appropriate. ayanami root # gcc --version gcc (GCC) 3.3.1 (Gentoo Linux 3.3.1, propolice) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ayanami root # gcc-config -c i686-pc-linux-gnu-3.3.1 As for jpeg-mmx versioning,... I have no idea.
Yes, it does still exist in GCC 3.3.1, because it is a bug in the library. The fix still fixes it for GCC 3.3.1, as i am using a very recent snapshot of the 3.3 branch and jpeg-mmx compiles fine. Basically, PIC needs a register to do memory addressing, and the assembly tries to use ALL the registers and do memory addressing... so when it clobbers all the registers, the compiler complains, because it needs one of them. If my assesment of this is incorrect anywhere, please post. I am not 100% certain, but this is the best I could figure out based on reading the docs on PIC in the GCC manual. And, freeing up a register does fix the problem. Anywho, thought I'd post that the fix works for 3.3.1 as well. -Chandler Carruth
this bug is still here, patch works, and gcc-3.3.1-r1 was marked ~x86
Created attachment 17394 [details, diff] Patch to jpeg-mmx ebuild In the interest of hurrying the fix, here's a patch to the ebuild. Should just be a matter of applying this patch to the ebuild, saving the other one as files/gcc33-fpic.patch and committing.
Fix is in portage.
