Re: Xtensa port, part 5: a minor testsuite change

[Bob Wilson <bwilson at tensilica dot com>]

Because the Xtensa instruction set is very tightly encoded for code 
density, we have a lot of offset restrictions.  There tend to be pretty 
complicated interactions between all the offset restrictions.  When we 
first designed this system (egcs-1.0.3 timeframe), the iterative 
relaxation in the assembler seemed to be a better solution than handling 
this in GCC.  This approach seems to be working well so far.

This one case of relaxing to an indirect jump requires some cooperation 
from GCC, because the assembler cannot easily identify an available 
register to hold the target address.  We plan to have GCC conservatively 
estimate the distance to the jump target, and when this distance exceeds 
some limit, we'll reserve a register for the assembler to use if 
necessary.  Since we haven't yet hit this problem in any real code 
(excluding this testcase), fixing this has been a relatively low 
priority for us.

In the meantime, I wanted to mark this test as an expected failure so 
that I could get our port to pass the tests cleanly.  It's certainly not 
a big deal if you don't want to make this change -- if nothing else, 
seeing that failure all the time might motivate me to fix it sooner :-) 
  I'd still prefer to mark the expected failure, though.

Richard Henderson wrote:

> On Fri, Nov 30, 2001 at 11:35:54AM -0800, Bob Wilson wrote:
> 
>>	* gcc.c-torture/compile/20001226-1.x: Make this test an expected
>>	failure for Xtensa targets.  The test is so big that it exceeds
>>	the allowed range for the jump instruction, and the Xtensa
>>	assembler is not yet capable of relaxing jumps into indirect
>>	jumps.
>>
> 
> Alternately, gcc can do this.  In fact, that's exactly what
> this is intended to test.