From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 1035) id 5FA6F3858D38; Thu, 16 May 2024 10:14:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5FA6F3858D38 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1715854445; bh=MQ2+ZvO7AQdWc97u6Ih0Eom3sJ1NUz+h3MgEKhXf7g0=; h=From:To:Subject:Date:From; b=ZrTqZf+B6A4D3KOfh55r5ki35DZIKKKeIcGFRBzEJoE64yrX71kmvm6sdZcoiaGg1 U6aEoaFE+55U5uoVB8D8IpXR+MGfUqQmGDrnM1qfIjMWH7x0xKGvSitgrthFvtmdAo QZYXwHd5eLRK9RqYgWKgnSAB9y1JemFDYssnu3Vk= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable From: Richard Earnshaw To: binutils-cvs@sourceware.org Subject: [binutils-gdb] arm: remove incorrect handling of FP bignums in move_or_literal_pool X-Act-Checkin: binutils-gdb X-Git-Author: Richard Earnshaw X-Git-Refname: refs/heads/master X-Git-Oldrev: 9c54f520db35bea9d02d121d4f368a5d196c5a8c X-Git-Newrev: 7e544ad81a55941cda38d9195e79dace243f48d0 Message-Id: <20240516101405.5FA6F3858D38@sourceware.org> Date: Thu, 16 May 2024 10:14:05 +0000 (GMT) List-Id: https://sourceware.org/git/gitweb.cgi?p=3Dbinutils-gdb.git;h=3D7e544ad81a55= 941cda38d9195e79dace243f48d0 commit 7e544ad81a55941cda38d9195e79dace243f48d0 Author: Richard Earnshaw Date: Wed May 15 16:06:28 2024 +0100 arm: remove incorrect handling of FP bignums in move_or_literal_pool =20 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. =20 - It tested X_add_number =3D=3D -1, but an FP bignum is indicated by any value <=3D 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. =20 Since I can't construct a viable testcase, I've just removed the existi= ng code and made the function error out in this case: this seems more sens= ible than generating wrong code or trying to write something more complex th= at 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 =3D=3D O_big) { - LITTLENUM_TYPE w[X_PRECISION]; - LITTLENUM_TYPE * l; + LITTLENUM_TYPE *l; =20 - if (inst.relocs[0].exp.X_add_number =3D=3D -1) + if (inst.relocs[0].exp.X_add_number <=3D 0) /* FP value. */ { - gen_to_words (w, X_PRECISION, E_PRECISION); - l =3D 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, =3D1.0 + VLDR d0, =3D55.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 =3D _("constant expression not supported"); + return true; } else l =3D generic_bignum;