From: Paolo Bonzini <pbonzini@redhat.com>
To: Richard Henderson <rth@twiddle.net>,
Peter Maydell <peter.maydell@linaro.org>
Cc: Blue Swirl <blauwirbel@gmail.com>,
Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] target-sparc: fix 32-bit truncation in fpackfix
Date: Wed, 4 Nov 2015 11:45:22 +0100 [thread overview]
Message-ID: <5639E1C2.80902@redhat.com> (raw)
In-Reply-To: <5639DA14.3020507@twiddle.net>
On 04/11/2015 11:12, Richard Henderson wrote:
> On 11/02/2015 04:13 PM, Peter Maydell wrote:
>> On 2 November 2015 at 14:48, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>>
>>>
>>> On 02/11/2015 15:09, Peter Maydell wrote:
>>>>>> diff --git a/target-sparc/vis_helper.c b/target-sparc/vis_helper.c
>>>>>> index 383cc8b..45fc7db 100644
>>>>>> --- a/target-sparc/vis_helper.c
>>>>>> +++ b/target-sparc/vis_helper.c
>>>>>> @@ -447,7 +447,7 @@ uint32_t helper_fpackfix(uint64_t gsr,
>>>>>> uint64_t rs2)
>>>>>> for (word = 0; word < 2; word++) {
>>>>>> uint32_t val;
>>>>>> int32_t src = rs2 >> (word * 32);
>>>>>> - int64_t scaled = src << scale;
>>>>>> + int64_t scaled = (int64_t)src << scale;
>>>>>> int64_t from_fixed = scaled >> 16;
>>>> This will now shift left into the sign bit of a signed integer,
>>>> which is undefined behaviour.
>>>
>>> Why "now"? It would have done the same before.
>>
>> True, but I was reviewing the new code rather than the
>> code you were taking away :-)
>>
>> Incidentally, that manual says the fpackfix and fpack32 insns
>> use a 4 bit GSR.scale_factor value, but our code is masking
>> by 0x1f in helper_fpack32 and helper_fpackfix. Which is right?
>
> The 2011 manual has 5 bits for fpack32 and fpackfix; fpack16 uses only 4
> bits.
>
> I do think we'd be better served by casting to uint64_t on that line.
> Note that fpackfix requires the same correction. And it wouldn't hurt
> to cast to uint32_t in fpack16, lest we anger the self-same shifting gods.
Hmmm.. say src = -0x80000000, scale = 1;
scaled = (uint64_t)-0x8000000 << 1 = 0xffffffff00000000
from_fixed = 0xffffffff00000000 >> 16 = 0x0000ffffffff0000
Now from_fixed is positive and you get 32767 instead of -32768. In
other words, we would have to cast to uint64_t on the scaled assignment,
and back to int64_t on the from_fixed assignment. I must be
misunderstanding your suggestion.
Paolo
next prev parent reply other threads:[~2015-11-04 10:45 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-02 14:05 [Qemu-devel] [PATCH] target-sparc: fix 32-bit truncation in fpackfix Paolo Bonzini
2015-11-02 14:09 ` Peter Maydell
2015-11-02 14:48 ` Paolo Bonzini
2015-11-02 15:13 ` Peter Maydell
2015-11-02 15:50 ` Paolo Bonzini
2015-11-04 10:12 ` Richard Henderson
2015-11-04 10:45 ` Paolo Bonzini [this message]
2015-11-04 11:05 ` Richard Henderson
2015-11-04 12:46 ` Paolo Bonzini
2015-11-04 14:07 ` Markus Armbruster
2015-11-04 16:06 ` Paolo Bonzini
2015-11-04 17:53 ` Markus Armbruster
2015-11-05 9:11 ` Paolo Bonzini
2015-11-04 23:36 ` Mark Cave-Ayland
2015-11-05 9:12 ` Paolo Bonzini
2015-11-05 9:20 ` Richard Henderson
2015-11-05 9:25 ` Paolo Bonzini
2015-11-05 9:28 ` Richard Henderson
2015-11-05 9:43 ` Paolo Bonzini
2015-11-06 15:33 ` Mark Cave-Ayland
2015-11-06 15:43 ` Paolo Bonzini
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=5639E1C2.80902@redhat.com \
--to=pbonzini@redhat.com \
--cc=blauwirbel@gmail.com \
--cc=mark.cave-ayland@ilande.co.uk \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.