The attached sample code (test case stripped out of ffmpeg, reduced to what's necessary to trigger the error) fails to build w/ the ssa branch, works perfectly in 3.3.x, and from a quick look, the code seems to be ok.
Created attachment 5569 [details] test case test case
What is the command line you used?
The simplest is just gcc-ssa -c -o test.o dsputil_mmx.c Adding flags like -O2 or -fomit-frame-pointer doesn't change anything.
Also i686 is known have problems like this because of how many little registers they have.
True... Unfortunately we can't fix the CPUs. ;) Another note: It works with gcc 3.3.x only at -O1 and higher. [bero@build-athlon i386]$ gcc --version 2>&1 |head -n 1 gcc (GCC) 3.3.3 20040111 (Ark Linux 1.0 3.3.3-0.20040111.1ark) [bero@build-athlon i386]$ gcc-ssa --version 2>&1 |head -n 1 gcc-ssa (GCC) 3.5-tree-ssa 20040120 (Ark Linux 3.5-0.ssa20040120.1ark) [bero@build-athlon i386]$ gcc -O0 -c -o test.o dsputil_mmx.c dsputil_mmx.c: In function `h263_h_loop_filter_mmx': dsputil_mmx.c:45: error: can't find a register in class `GENERAL_REGS' while reloading `asm' [bero@build-athlon i386]$ gcc -O1 -c -o test.o dsputil_mmx.c [bero@build-athlon i386]$ gcc-ssa -O0 -c -o test.o dsputil_mmx.c dsputil_mmx.c: In function `h263_h_loop_filter_mmx': dsputil_mmx.c:45: error: can't find a register in class `GENERAL_REGS' while reloading `asm' [bero@build-athlon i386]$ gcc-ssa -O1 -c -o test.o dsputil_mmx.c dsputil_mmx.c: In function `h263_h_loop_filter_mmx': dsputil_mmx.c:45: error: can't find a register in class `GENERAL_REGS' while reloading `asm' [bero@build-athlon i386]$ gcc-ssa -O99 -c -o test.o dsputil_mmx.c dsputil_mmx.c: In function `h263_h_loop_filter_mmx': dsputil_mmx.c:45: error: can't find a register in class `GENERAL_REGS' while reloading `asm'
Really the code should not be using inline-asm but that is different story. I think the problem is that the tree-ssa is finding some common sub expressions and combining them which is causing reload (the register spiller) to fail to find registers/offsets for the contstraints.
Yes, all of this is quite silly, and should be using <mmintrin.h> instead. That said, I compute 4 required registers here, so we should have been ok. The bug appears to be that CSE isn't interested in generating more complex addressing modes for the memories here. Not sure why...
FWIF, the code is so silly because I've stripped out all parts not related to the problem. It's much more complex (and actually makes a bit of sense) if you don't remove the 30 lines between those that trigger the error. ;)
Subject: Re: [tree-ssa] Fails to compile ffmpeg on x86: can't find a register in class `GENERAL_REGS' while reloading `asm' On Wed, Feb 04, 2004 at 03:21:11AM -0000, bero at arklinux dot org wrote: > It's much more complex (and actually makes a bit of sense) if you don't > remove the 30 lines between those that trigger the error. ;) No, I've looked at the real code as well. It *still* ought to be using <mmintrin.h>. Either that or quit using C at all and use the assembler directly. r~
Minor as the inline-asm should not be used here.
I am having the same problem. But with these CFLAGS="-O -march=athlon-xp -funroll-loops -pipe" it works. O6 and O3 and O2 don't work. Johnny PS: don't hesitate to send me test code, or ask questions about my system. Maybe I am providing ssh access, if we cant't trace the bug otherwise.
This regression was brought in by the tree-ssa merge.
Created attachment 6313 [details] smaller testcase (258 bytes) Compile this without optimizations: cat > bug.i << EOF void h263_h_loop_filter_mmx (unsigned int *src) { asm volatile( "foo bar blah blah ..." : "=m" (*(src + 0)), "=m" (*(src + 1)), "=m" (*(src + 2)), "=m" (*(src + 3)), "=m" (*(src + 4)), "=m" (*(src + 5)), "=m" (*(src + 6)) ); } EOF gcc bug.i bug.i: In function `h263_h_loop_filter_mmx': bug.i:3: error: can't find a register in class `GENERAL_REGS' while reloading `asm' This fails for me with 3.3.4, 3.4.1, 3.5.0
testcase also fails here with gcc 3.4.0
Not a regression.
Same error message compiling util-linux on a athlon64. I can attach the compile log, if you want.
Forgot to add that I see that message with gcc 3.4.1, and I didn't have any problem with gcc 3.3.4
*** This bug has been marked as a duplicate of 11203 ***