[PATCH, ARM] Fix parsing of int/float immediates for Neon VMOV instructions

[Julian Brown]

Hi,

This patch fixes a failure to parse instructions of the form:

   vmov.i32 dX, #N

where N is between 1 and 31 (the valid integer values which the 
floating-point VMOV variant can accept). The solution isn't very nice, 
but the way things are at the moment, we don't really have coherent type 
information for the instruction in the right place as we're parsing -- 
I've added a FIXME to that effect. (Parsing is done kind of 
context-free, but context-sensitive parsing which knew about the type of 
the operands for the instruction at hand would probably be nicer in this 
case.)

(Floats are encoded into IEEE754-form early, during parsing. So, 10 and 
10.0 look very different coming out of the parser, and the correct 
immediate form to use is deduced during bit encoding.)

To use floating-point immediates, you must now explicitly use a decimal 
point or exponent, i.e.

   vmov.f32 dX, #10.0

not

   vmov.f32 dX, #10

The handling of -0 and 0 values is tweaked for vmov.f32 also (they must 
now be written 0.0 and -0.0), and the testsuite is altered accordingly.

Tested with cross to arm-none-eabi.

OK?

Cheers,

Julian

     gas/
     * config/tc-arm.c (parse_qfloat_immediate): Disallow integer
     syntax for floating-point immediates. Fix hex immediates,
     handle 0.0 and -0.0 specially.

     gas/testsuite/
     * gas/arm/neon-const.s: Use FP syntax for 0/-0.
     * gas/arm/vfp-neon-syntax-inc.s: Likewise, for 1.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gas-int-qfloat-fixes-1
URL: <https://sourceware.org/pipermail/binutils/attachments/20070302/c46d1b77/attachment.ksh>