From: Richard Earnshaw <rearnsha@sourceware.org>
To: binutils-cvs@sourceware.org
Subject: [binutils-gdb] arm: remove incorrect handling of FP bignums in move_or_literal_pool
Date: Thu, 16 May 2024 10:14:05 +0000 (GMT) [thread overview]
Message-ID: <20240516101405.5FA6F3858D38@sourceware.org> (raw)
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;
reply other threads:[~2024-05-16 10:14 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240516101405.5FA6F3858D38@sourceware.org \
--to=rearnsha@sourceware.org \
--cc=binutils-cvs@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).