So my tester started showing even more regressions on the sh3/sh4 runs 
recently (beyond the one recently reported in BZ triggered by some DCE 
related changes).  Bisection kept showing inconsistent results.  I was 
starting to think memory management error, but valgrind didn't flag 
anything.

After a bit of head-banging I was able to track it down to predicate 
tests called from the SH specific combiner passes.  And once I started 
getting inside the actual code for the predicate function it became 
pretty obvious.  The predicate routines are supposed to return a bool, 
fine and they dutifully set the low bit in %eax properly.

The *caller* was looking at the full register.  Uh-oh.  Naturally we 
became dependent on what happened to be in the upper 31 bits of a 
register.  That's why the bug would come and go so willy-nilly. This was 
ultimately chased down to an incorrect prototype in sh_treg_combine.cc  
for predicates functions defined via define_predicate.

Removing the bogus prototypes and instead including the generated 
tm-preds.h fixes this problem.  I also checked the other ports for 
similar problems (specifically looking for a extern int.*_operand, then 
for each of the hits looking to see if the predicate was defined via 
define_predicate).  No other ports had similar braindamage.

This fixes the most recent regressions in my tester for sh3/sh3eb and I 
strongly suspect sh4.  It does not fix 107704, but I think Richi and I 
both agree that's a visitation order issue and we were just getting 
lucky before.


Committing to the trunk.



Jeff