My favorite gcc trick is to compile and run the following two line, and then try to reconcile the results.<p>x = 7;<p>printf("%d %d %d",x++,++x,x++);<p>x = 7;<p>printf("%d %d %d",x++,x=2,x++);<p>Go ahead, try it, run it, and explain the output.
I find it hard to believe that you wouldn't know how many registers code should use. However - it's not C code, it's assembly code, so it seems unfair to blame gcc - a <i>C</i> compiler.
read comment #24:<p>Martin, you should realize that this problem <i>cannot</i> be solved. Yes,
there will perhaps be a time when this particular test case compiles,
though I think that is unlikely. But anyway, then there will be other
cases that fail.<p>The reason is dead simple: register allocation is NP-complete, so it
is even <i>theoretically</i> not possible to write register allocators that
always find a coloring. That means any register allocator will always
fail on some very constrained asm input. And you cannot allow it to
run indefinitely until a coloring is found, because then you've turned
the graph coloring problem into the halting problem because you can't
prove that a coloring exists and that the register allocator algorithm
will terminate.<p>So really it doesn't matter at all whether or not your specific inline
asm compiles or not. When yours does, someone else's will fail.