The function mk_AvDuplicateRI() stores 16 bytes to memory and then

fetches the data into a vector register.  The load was being
generated as a lvewx instead of a lvx instruction by the code:

      /* Effectively splat the r_src value to dst */
      addInstr(env, PPCInstr_AvLdSt( True/*ld*/, 4, dst, am_offset_zero ) );

The second argument controls which load instruction is generated.  The
second argument should have been 16 to generate the lvx instruction not
the lvewx instruction.  The issue was reported on the Freescale processor
for the vsptlb instruction.  The issue was not detected before because
the backend code generation used the same vector register to load into
as was used previously to create the data.  However, the code generation
is dependent on the HW/Distro/compiler.  If the same register isn't used
the bug appears.  The issue was found with Valgrind 3.10.0 on the Freescale
processor as the Valgrind code generation didn't happen to pick the same
register to do the load into.

The issue was reported in bugzilla 339182.

git-svn-id: svn://svn.valgrind.org/vex/trunk@2960

diff --git a/VEX/priv/host_ppc_isel.c b/VEX/priv/host_ppc_isel.c
index 91f5620160b97c678b1fb03250dba96aef17e30f..fcbb53e845b9de3dec83e23595b7af8e55a5f627 100644 (file)
--- a/VEX/priv/host_ppc_isel.c
+++ b/VEX/priv/host_ppc_isel.c
@@ -1327,7 +1327,7 @@ static HReg mk_AvDuplicateRI( ISelEnv* env, IRExpr* e, IREndness IEndianess )
       }
 
       /* Effectively splat the r_src value to dst */
-      addInstr(env, PPCInstr_AvLdSt( True/*ld*/, 4, dst, am_offset_zero ) );
+      addInstr(env, PPCInstr_AvLdSt( True/*ld*/, 16, dst, am_offset_zero ) );
       add_to_sp( env, 32 );       // Reset SP
 
       return dst;