[binutils-gdb] arm: remove incorrect handling of FP bignums in move_or_literal_pool

[Richard Earnshaw]

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7e544ad81a55941cda38d9195e79dace243f48d0

commit 7e544ad81a55941cda38d9195e79dace243f48d0
Author: Richard Earnshaw <rearnsha@arm.com>
Date:   Wed May 15 16:06:28 2024 +0100

    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.

Diff:
---
 gas/config/tc-arm.c | 30 ++++++++++++++++++++++++------
 1 file changed, 24 insertions(+), 6 deletions(-)

diff --git a/gas/config/tc-arm.c b/gas/config/tc-arm.c
index 343b2e77d7c..41bcfb8dee2 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;