diff options
author | Richard Earnshaw <rearnsha@arm.com> | 2024-05-15 16:06:28 +0100 |
---|---|---|
committer | Richard Earnshaw <rearnsha@arm.com> | 2024-05-16 11:10:15 +0100 |
commit | 7e544ad81a55941cda38d9195e79dace243f48d0 (patch) | |
tree | ad240fd48c685b87448685e1d24288b288ad6e58 | |
parent | 9c54f520db35bea9d02d121d4f368a5d196c5a8c (diff) | |
download | fsf-binutils-gdb-7e544ad81a55941cda38d9195e79dace243f48d0.zip fsf-binutils-gdb-7e544ad81a55941cda38d9195e79dace243f48d0.tar.gz fsf-binutils-gdb-7e544ad81a55941cda38d9195e79dace243f48d0.tar.bz2 |
arm: remove incorrect handling of FP bignums in move_or_literal_pool
This hunk of code in move_or_literal_pool just looks wrong, but I
can't find a testcase that will tickle it to prove it. It looks a bit
like it was intended to catch cases where a bignum contained a
floating-point value, but there were a number of problems with it.
- It tested X_add_number == -1, but an FP bignum is indicated by any
value <= 0.
- It converted the floating-point value to extended precision, but
that's not used on Arm beyond the legacy FPA code. No attempt was
made to match the FP value to the intended memory/mov operation.
Since I can't construct a viable testcase, I've just removed the existing
code and made the function error out in this case: this seems more sensible
than generating wrong code or trying to write something more complex that
can't be tested anyway.
-rw-r--r-- | gas/config/tc-arm.c | 30 |
1 files changed, 24 insertions, 6 deletions
diff --git a/gas/config/tc-arm.c b/gas/config/tc-arm.c index 343b2e7..41bcfb8 100644 --- a/gas/config/tc-arm.c +++ b/gas/config/tc-arm.c @@ -8922,14 +8922,32 @@ move_or_literal_pool (int i, enum lit_type t, bool mode_3) uint64_t v; if (inst.relocs[0].exp.X_op == O_big) { - LITTLENUM_TYPE w[X_PRECISION]; - LITTLENUM_TYPE * l; + LITTLENUM_TYPE *l; - if (inst.relocs[0].exp.X_add_number == -1) + if (inst.relocs[0].exp.X_add_number <= 0) /* FP value. */ { - gen_to_words (w, X_PRECISION, E_PRECISION); - l = w; - /* FIXME: Should we check words w[2..5] ? */ + /* FIXME: The code that was here previously could not + work. Firstly, it tried to convert a floating point + number into an extended precision format, but only + provided a buffer of 5 littlenums, which was too + small. Secondly, it then didn't deal with the value + converted correctly, just reading out the first 4 + littlenum fields and assuming that could be used + directly. + + I think the code was intended to handle expressions + such as: + + LDR r0, =1.0 + VLDR d0, =55.3 + + but the parsers currently don't permit floating-point + literal values to be written this way, so this code + is probably unreachable. To be safe, we simply + return an error here. */ + + inst.error = _("constant expression not supported"); + return true; } else l = generic_bignum; |