Re: ARM error with glibc (Illegal value for co-processor offset)

[Richard Earnshaw <rearnsha at arm dot com>]

> On Tue, May 29, 2001 at 09:54:20PM +0100, Philip Blundell wrote:
> > This is bug #817.
> 
> Which, btw, I can't reproduce with current sources.  Can you
> either confirm it's been fixed in the last 12 days, or send
> a different test case?  Or get Richard Earnshaw to ack the
> patch on general "it looks right" principals?

The patch achieves the correct result, but I don't like the way it splits 
responsibility for adjusting for the fix size between the attribute and 
the code.  In terms of performance, all these adjustments should be 
precalculated and placed in the neg_pool_range attribute for the 
instruction; in terms of clarity, neg_pool_range should just be the 
spanning range of the insn pattern; but we can't take the latter approach 
to the extreme since we cannot make the code compensate easily for the PC 
adjustment (which is arm/thumb dependent), or more importantly for the 
offset of the loading instruction within a multi-instruction insn pattern.

I think the cleanest patch is to place the adjustment in the insn 
attributes (keep all the mess in one place); there are not more than four 
or five such insns that handle double-word operations with a negative 
offset.

However, I don't have time to fix the bug myself this week, so is it 
acceptable to install the patch on the branch only, and then leave the PR 
open (perhaps after reducing its priority to medium)?

R.