This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH, ARM] Fix out-of-range immediate assembly errors on 64-bit hosts
- From: Nick Clifton <nickc at redhat dot com>
- To: Julian Brown <julian at codesourcery dot com>
- Cc: binutils at sources dot redhat dot com
- Date: Mon, 12 Jun 2006 12:32:18 +0100
- Subject: Re: [PATCH, ARM] Fix out-of-range immediate assembly errors on 64-bit hosts
- References: <4489AB12.firstname.lastname@example.org>
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
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 ?