Yep its ugly too. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 55206 [details] libsdl-1.2.8-r1.ebuild.patch
yeah, that patch def does not look like we can accept it ... perhaps it'd be better to fix the source code than disable features ? :p
Yes I know, but its a temporal fix.
temporal fixes for gcc4 dont go into portage
gcc-4 isn't supported right now. If you supply a non-hackish patch to address this, reopen and we'll take a look.
New patch for gcc4 is here. Tested without gcc2 patchs.
Created attachment 56322 [details] SDL-1.2.8-gcc4.patch
This patch is applied in portage, but you can only compile libsdl with -O0 because of libsdl-1.2.8-gcc2.patch.bz2. Removing it allows you to compile libsdl fine with regular optimizations. I don't know enough asm to know what sort of voodoo is happening there and why it would be screwing GCC4 up. Anyone else have any ideas? When the patch is applied, the error GCC4 gives is: i686-pc-linux-gnu-gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"SDL\" -DVERSION=\"1.2.8\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_LIBASOUND=1 -I. -I. -mtune=athlon-mp -march=athlon-mp -O2 -fomit-frame-pointer -pipe -ftracer -fweb -ftree-vectorize -Wall -DENABLE_DUMMYVIDEO -DDISKAUD_SUPPORT -DUSE_DLOPEN -DUSE_ASMBLIT -I./hermes -I../../src/hermes -DALSA_SUPPORT -DALSA_DYNAMIC=libasound.so.2 -DUSE_DLVSYM -DESD_SUPPORT -DESD_DYNAMIC=libesd.so.0 -DENABLE_X11 -DXTHREADS -I./include -I./src/video -DXFREE86_VM -DXFREE86_VMGAMMA -DXFREE86_XV -DENABLE_SVGALIB -DHAVE_OPENGL -DUSE_INPUT_EVENTS -D_REENTRANT -DSDL_USE_PTHREADS -DHAVE_SIGACTION -I../../include -I../../include/SDL -I../../src -I../../src/main/linux -I../../src/audio -I../../src/video -I../../src/video/XFree86/extensions -I../../src/events -I../../src/joystick -I../../src/cdrom -I../../src/thread -I../../src/timer -I../../src/endian -I../../src/file -I../../src/thread -c SDL_yuv_mmx.c -fPIC -DPIC -o .libs/SDL_yuv_mmx.o SDL_yuv_mmx.c: In function 'ColorRGBDitherYV12MMX1X': SDL_yuv_mmx.c:113: error: can't find a register in class 'INDEX_REGS' while reloading 'asm' make[3]: *** [SDL_yuv_mmx.lo] Error 1
halcy0n: Saw this bug in your blog. the source of the asm error is reasonably simple. under higher -O levels, GCC tries to preserve values in registers longer to re-use them. x86 is a sucky architecture, in that only a very small number of registers are available - the error you see is that it wants 5 registers for that asm block, but 5 registers aren't available at that point. I suspect that the problem would go away if you added the list of registers that is clobbered to the correct section of the asm code (look it up in 'info gcc'), then things should be more sane.
Modifying that patch is a little beyond me. If someone wants to fix it, go for it, but for now, I made it so the patch is conditionally applied and only isn't applied for gcc 4. So, now compiling libsdl with >-O0 should work fine.
