GCC Bugzilla Bug 13850

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 an attachment (id=5569) [edit]
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 an attachment (id=6313) [edit]
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 ***