[PATCH, ARM] Fix out-of-range immediate assembly errors on 64-bit hosts

[Nick Clifton]

Hi Julian,


> This patch fixes some immediate-out-of-range errors for VBIC, VORR etc. 
> on 64-bit hosts. On such hosts, the X_add_number field of expressions 
> will be 64 bits wide. INT_MIN and INT_MAX are used to signify that any 
> immediate may be accepted for parse_immediate: unfortunately on a 64-bit 
> host, 0xff000000 for instance is then interpreted as a positive integer 
> outside that range.

Sorry - can you explain that last part again please ?  I get how INT_MIN 
and INT_MAX are being used to indicate "any integer value is acceptable" 
to parse_immediate(), but where does this 0xffff0000 value come from and 
why would it cause problems for parse_immediate() ?

> I've just made passing INT_MIN/INT_MAX disable the 
> check instead, though I'm not very fond of that solution.

There appears to be only once place where INT_MAX/INT_MIN are used, so 
maybe it would be cleaner to change that code to pass realistic minimum 
and maximum values ?

>     * config/tc-arm.c (parse_immediate): Handle 64-bit X_add_number
>     case.

That sentence is not quite true.  The change is to skip the range checks 
when the range is INT_MIN -> INT_MAX.


> !       /* If we're on a 64-bit host, then a 64-bit number can be returned using
> ! 	 O_constant.  We have to be careful not to break compilation for
> ! 	 32-bit X_add_number, though.  */
> !       if ((exp.X_add_number & ~0xffffffffl) != 0)
> ! 	{
> !           inst.operands[i].reg = ((exp.X_add_number >> 16) >> 16) & 0xffffffff;
> ! 	  inst.operands[i].regisimm = 1;
> ! 	}

I am a little bit confused here.  How is ((x >> 16) >> 16) different 
from (x >> 32) ?  If not, then why express it that way ?

Cheers
   Nick