GCC 4.0 (part 2)

[luisfelipe]

Well, xine-lib 1.1.0-r3 isn't compiling here even with gcc-3.4.x , so I guess this might not be gcc-4.0 related.

[chtephan]

i don't see anyone reporting that fortran has been broken for weeks on comp.gcc.devel. i would think that kind of thing would be noticed pretty quickly, so i'm guessing it's gentoocentric.

Nah, I don't think so. gcc is nearly completely self-containing and the bug is a problem in the source which has nothing to do with an external dependency. CVS is always in a flux and people know that things can break. A snapshot from last month was broken too and the next one was okay again without anyone complaining. The gcc 4.0 is currently not in a critical phase (like the two weeks before a release), so people are allowed to temporarily break stuff.

[chtephan]

Problems compiling xine-lib-1.1.0-r3, libsdl-1.2.9 with gcc-4.0.2_beta20050901
changing CFLAGS doesnt help

Yeah, I'm seeing this too. Some older versions worked, but I'm not willing to figure out what the hell is going on again. The bugs have *again* something to do with register allocation, this is geting tiresome...

[rhill]

here's the fix for xine-lib:

http://metawire.org/~dirtyepic/xine-lib-1.1.0-r3.ebuild

hardened gcc 4 might still take issue with it. can someone test it out?


edit: https://bugs.gentoo.org/show_bug.cgi?id=104966

[rhill]

i don't see anyone reporting that fortran has been broken for weeks on comp.gcc.devel. i would think that kind of thing would be noticed pretty quickly, so i'm guessing it's gentoocentric.

Nah, I don't think so. gcc is nearly completely self-containing and the bug is a problem in the source which has nothing to do with an external dependency. CVS is always in a flux and people know that things can break. A snapshot from last month was broken too and the next one was okay again without anyone complaining. The gcc 4.0 is currently not in a critical phase (like the two weeks before a release), so people are allowed to temporarily break stuff.

ah i thought i remembered it being broken the week before too.

[chtephan]

here's the fix for xine-lib:

http://metawire.org/~dirtyepic/xine-lib-1.1.0-r3.ebuild

What did you change --disable-fpic? I don't think that's a very good solution.

x86 is one of the few arches that can have non-pic shared libraries and even there it's not the best idea since it slows down the loading process, disables prelink and wastes memory. And on a hardened gcc with pie you will have PIC anyway.

xine-lib is supposed to compile with -fPIC, so something is broken.

[j-m]

here's the fix for xine-lib:

http://metawire.org/~dirtyepic/xine-lib-1.1.0-r3.ebuild

What did you change --disable-fpic? I don't think that's a very good solution.

Yeah, that's not an acceptable solution at all.

[PrakashP]

Well, another hack would be this (not cleaned up):

Code: Select all

#if __GNUC__ < 4
typedef char v8qi __attribute__ ((__mode__(__V8QI__)));
typedef short v4hi __attribute__ ((__mode__(__V4HI__)));
typedef int   v2si __attribute__ ((__mode__(__V2SI__)));
typedef int   di   __attribute__ ((__mode__(__DI__)));
#else
typedef char v8qi __attribute__ ((vector_size (8)));
typedef short v4hi __attribute__ ((vector_size (8)));
typedef int   v2si __attribute__ ((vector_size (8)));
typedef int   di   __attribute__ ((vector_size (8)));
#endif
static inline void transpose4x4(uint8_t *dst, uint8_t *src, int dst_stride, int src_stride){
v8qi m0,m1,m2,m3;

m0 = __builtin_ia32_punpcklbw(*(v8qi*)(src + 1*src_stride),*(v8qi*)(src + 0*src_stride));
m1 = __builtin_ia32_punpcklbw(*(v8qi*)(src + 3*src_stride),*(v8qi*)(src + 2*src_stride));
m2 = (v8qi)__builtin_ia32_punpcklwd((v4hi)m1,(v4hi)m0);
m3 = (v8qi)__builtin_ia32_punpckhwd((v4hi)m1,(v4hi)m0);
*(v8qi*)(dst + 0*dst_stride) = m2;
*(v8qi*)(dst + 1*dst_stride) = (v8qi)__builtin_ia32_punpckhdq((v2si)m2,(v2si)m2);
*(v8qi*)(dst + 2*dst_stride) = m3;
*(v8qi*)(dst + 3*dst_stride) = (v8qi)__builtin_ia32_punpckhdq((v2si)m3,(v2si)m3);
}

At least this file compiles for me. Let's see whether another file makes trouble.

[chtephan]

I'm wondering if ffmpeg might be better of using the gcc mmx intrinsics in general, since he might do better register allocation and scheduling, especially with this inlining. It also (apparently) solves the problem 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.

And, BTW, if you include <mmintrin.h> you can have even nicer code, since all the defines are already there.

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.

This compiles for me:

Code: Select all

--- xine-lib-1.1.0.orig/src/libffmpeg/libavcodec/i386/dsputil_mmx.c     2005-07-19 22:31:09.000000000 +0200
+++ xine-lib-1.1.0/src/libffmpeg/libavcodec/i386/dsputil_mmx.c  2005-09-07 14:48:00.000000000 +0200
@@ -616,15 +616,22 @@ static void h263_v_loop_filter_mmx(uint8

 static inline void transpose4x4(uint8_t *dst, uint8_t *src, int dst_stride, int src_stride){
     asm volatile( //FIXME could save 1 instruction if done as 8x4 ...
-        "movd  %4, %%mm0               \n\t"
-        "movd  %5, %%mm1               \n\t"
-        "movd  %6, %%mm2               \n\t"
-        "movd  %7, %%mm3               \n\t"
+        "movd  %0, %%mm0               \n\t"
+        "movd  %1, %%mm1               \n\t"
+        "movd  %2, %%mm2               \n\t"
+        "movd  %3, %%mm3               \n\t"
         "punpcklbw %%mm1, %%mm0                \n\t"
         "punpcklbw %%mm3, %%mm2                \n\t"
         "movq %%mm0, %%mm1             \n\t"
         "punpcklwd %%mm2, %%mm0                \n\t"
         "punpckhwd %%mm2, %%mm1                \n\t"
+        :
+        :  "m" (*(uint32_t*)(src + 0*src_stride)),
+           "m" (*(uint32_t*)(src + 1*src_stride)),
+           "m" (*(uint32_t*)(src + 2*src_stride)),
+           "m" (*(uint32_t*)(src + 3*src_stride))
+    );
+    asm volatile(
         "movd  %%mm0, %0               \n\t"
         "punpckhdq %%mm0, %%mm0                \n\t"
         "movd  %%mm0, %1               \n\t"
@@ -636,10 +643,7 @@ static inline void transpose4x4(uint8_t
           "=m" (*(uint32_t*)(dst + 1*dst_stride)),
           "=m" (*(uint32_t*)(dst + 2*dst_stride)),
           "=m" (*(uint32_t*)(dst + 3*dst_stride))
-        :  "m" (*(uint32_t*)(src + 0*src_stride)),
-           "m" (*(uint32_t*)(src + 1*src_stride)),
-           "m" (*(uint32_t*)(src + 2*src_stride)),
-           "m" (*(uint32_t*)(src + 3*src_stride))
+        :
     );
 }

Can somebody test that? I don't know where exactly that function is used.

[Exner]

Problems compiling xine-lib-1.1.0-r3, libsdl-1.2.9 with gcc-4.0.2_beta20050901
changing CFLAGS doesnt help

Code: Select all

 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 -DENABLE_IPV6 -O1 -frename-registers -ffunction-sections -mno-sse -fomit-frame-pointer -c dsputil_mmx.c  -fPIC -DPIC -o .libs/dsputil_mmx.o
In file included from dsputil_mmx.c:2407:
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

Have you tried without -frename-registers ?

[chtephan]

No, that won't help. There is no way this function is going to work with -fPIC the way it is coded.

You have six multi-purpose registers available: eax, ebx, ecx, edx, esi and edi.

You have eight memory locations: a, a+b, a+b*2, a+b*3, c, c+d, c+d*2, c+d*3. All except the *3 addresses can be expressed using an x86 memory expression. So you need a, b, c, d plus two other pre-computed locations kept in a register. You need all six registers. If you omit the frame pointer, you get ebp too. But if ebx (-fPIC) and ebp (frame-pointer) are in use there is no way gcc is going to make this work.

[PrakashP]

And, BTW, if you include <mmintrin.h> you can have even nicer code, since all the defines are already there.

Nicer, maybe, but usually slower (esp ggc 3.4 and broken gcc4 versions).

[chtephan]

Yes, that's unfortunate. With your code the result seemed slightly better than the asm code with the current gcc 4.0. I guess this was pure luck.

Describing the processor internals isn't very easy. So sometimes when they try to tune things a bit, like making some operations cheaper by using integer registers instead of mmx/sse ones the compiler starts doing this where he really shouldn't.

With Apple we'll perhaps see a big improvement in that area, they already improved altivec a lot in gcc 4 compared to gcc 3 (while x86 type architectures have degraded).

[PrakashP]

gcc 4.0 is very good at scheduling SIMD code. It is about 10% faster and (unless broken) it makes no difference using mmintrin.h. gcc 3.4 even produces wrong code in case of at least SSE intrinsics.

[Exner]

I have a couple of packages now that wont compile with gcc-4.0.2_beta20050901 where they did with previous versions. dev-libs/boost-1.32.0-r4 being one of them.

[Halcy0n]

I have a couple of packages now that wont compile with gcc-4.0.2_beta20050901 where they did with previous versions. dev-libs/boost-1.32.0-r4 being one of them.

The boost bug is a known problem, I don't have access to my email right now, so I don't have the upstream bug number. Its because of some recent changes to the C++ frontend.

[luisfelipe]

I'm having problems compiling kdelibs too. Has anyone experienced this ?

[Halcy0n]

I'm having problems compiling kdelibs too. Has anyone experienced this ?

I personally don't use any KDE stuff, but could you be more precise? And give the output of `emerge info'?

[zomps]

I'm having problems compiling kdelibs too. Has anyone experienced this ?

no problem with svn build

[zomps]

Problems compiling xine-lib-1.1.0-r3, libsdl-1.2.9 with gcc-4.0.2_beta20050901
changing CFLAGS doesnt help

Code: Select all

 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 -DENABLE_IPV6 -O1 -frename-registers -ffunction-sections -mno-sse -fomit-frame-pointer -c dsputil_mmx.c  -fPIC -DPIC -o .libs/dsputil_mmx.o
In file included from dsputil_mmx.c:2407:
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

Have you tried without -frename-registers ?

Tested it, same result

[Halcy0n]

Problems compiling xine-lib-1.1.0-r3, libsdl-1.2.9 with gcc-4.0.2_beta20050901
changing CFLAGS doesnt help

Code: Select all

 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 -DENABLE_IPV6 -O1 -frename-registers -ffunction-sections -mno-sse -fomit-frame-pointer -c dsputil_mmx.c  -fPIC -DPIC -o .libs/dsputil_mmx.o
In file included from dsputil_mmx.c:2407:
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

Have you tried without -frename-registers ?

Tested it, same result

https://bugs.gentoo.org/show_bug.cgi?id=104966
Please try the patch I have attached there.

[zomps]

https://bugs.gentoo.org/show_bug.cgi?id=104966
Please try the patch I have attached there.

Will this same method fix libsdl-1.2.9 build?

Code: Select all

 i686-pc-linux-gnu-gcc -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DPACKAGE="SDL" -DVERSION="1.2.9" -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. -O1 -Wall -DENABLE_DUMMYVIDEO -DDISKAUD_SUPPORT -DUSE_DLOPEN -DUSE_ASMBLIT -I./hermes -I../../src/hermes -DALSA_SUPPORT -DALSA_DYNAMIC=libasound.so.2 -DUSE_DLVSYM -DENABLE_X11 -DXTHREADS -I./include -I./src/video -DXFREE86_VM -DXFREE86_VMGAMMA -DXFREE86_XV -DHAVE_OPENGL -DUSE_INPUT_EVENTS -D_REENTRANT -DSDL_USE_PTHREADS -DHAVE_SIGACTION -DHAVE_LINUX_VERSION_H -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 'GENERAL_REGS' while reloading 'asm'

[zomps]

https://bugs.gentoo.org/show_bug.cgi?id=104966
Please try the patch I have attached there.

Will this same method fix libsdl-1.2.9 build?

My bad, it tougth there was the only PIC disabling patch

[zomps]

https://bugs.gentoo.org/show_bug.cgi?id=104966
Please try the patch I have attached there.

Yes it helps

[chtephan]

I really don't like the push/pop instructions there.

You 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.

€: Patch posted on the bugzillla bug.