On 2 November 2015 at 14:05, Paolo Bonzini <pbonz...@redhat.com> wrote: > This is reported by Coverity. The algorithm description at > ftp://ftp.icm.edu.pl/packages/ggi/doc/hw/sparc/Sparc.pdf suggests > that the 32-bit parts of rs2, after the left shift, is treated > as a 64-bit integer. Bits 32 and above are used to do the > saturating truncation. > > Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> > --- > target-sparc/vis_helper.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > 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. thanks -- PMM
