Re: [Valgrind-users] false positive?!?

[Julian S. <js...@ac...>]

> mov    0x40(%rbp),%eax
> or     $0x1,%eax
> inc    %ax
> je     0x504ba10 <_ZN16QXmlSimpleReader11parsePrologEv+1120>
>
> I don't know why an ushort is loaded to eax

Either it's a harmless gcc oddity, or it's to observe some kind of
store-to-load-forwarding optimisation guideline for your CPU.  
But that's not important right now.

> but as only ax is 
> incremented why does this trigger a warning in valgrind?

Because memcheck incorrectly believes (from the point of view of the
definedness tracking) that the 'je' depends on the carry flag
(%rflags.c).  However that is not changed by the 'inc' but it is
set by the 'or', which since that used a half-garbage value from
the stack, sets it to 'undefined'.

Never mind.  Try this: in VEX/priv/guest-amd64/ghelper.c function
guest_amd64_spechelper find the case for DECW (will be obvious,
near line 1188) and after it add this:

      /*---------------- INCW ----------------*/

      if (isU64(cc_op, AMD64G_CC_OP_INCW) && isU64(cond, AMD64CondZ)) {
         /* 16-bit inc, then Z --> test dst == 0 */
         return unop(Iop_1Uto64,
                     binop(Iop_CmpEQ64, 
                           binop(Iop_Shl64,cc_dep1,mkU8(48)), 
                           mkU64(0)));
      }

Rebuild (make clean ; make ; make install) and try again.  Does
that fix it?

If that doesn't work try instead with AMD64CondNZ and Iop_CmpNE64.

J