|
From: <Woe...@on...> - 2006-10-19 22:18:59
|
Hi,
I get this warnings from Qt 3 code with GCC 4.1.1 on AMD64:
Conditional jump or move depends on uninitialised value(s)
for this code:
if (atEnd()) ...
with=20
inline bool QXmlSimpleReader::atEnd()
{ return (c.unicode()|0x0001) =3D=3D 0xffff; }
class QChar {
ushort &unicode() { return ucs; }
ushort ucs;
}
the disassembly is:
mov 0x40(%rbp),%eax
or $0x1,%eax
inc %ax
je 0x504ba10 <_ZN16QXmlSimpleReader11parsePrologEv+1120>
I don't know why an ushort is loaded to eax but as only ax is=20
incremented why does this trigger a warning in valgrind?
Cheers,
Andr=E9
|
|
From: Julian S. <js...@ac...> - 2006-10-19 22:26:54
|
> I don't know why an ushort is loaded to eax but as only ax is > incremented why does this trigger a warning in valgrind? ... and this is with which version of Valgrind? J |
|
From: <Woe...@on...> - 2006-10-19 23:23:01
|
On Friday 20 October 2006 00:26, Julian Seward wrote: > > I don't know why an ushort is loaded to eax but as only ax is > > incremented why does this trigger a warning in valgrind? > > ... and this is with which version of Valgrind? Bah, the most important information :-( I had this with 3.2.0 and now with 3.2.1 too. |
|
From: Julian S. <js...@ac...> - 2006-10-20 00:38:53
|
> 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
|
|
From: <Woe...@on...> - 2006-10-20 07:37:16
|
On Friday 20 October 2006 02:38, Julian Seward wrote:
> > 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'.
My assembler knowledge is a bit rusty, 'or' changes the carry flag?
> 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 =3D=3D 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?
I tried it with 3.2.1 and it works :-) Thanks!
Cheers,
Andr=E9
|
|
From: Julian S. <js...@ac...> - 2006-10-20 09:38:46
|
> My assembler knowledge is a bit rusty, 'or' changes the carry flag? Yup. > I tried it with 3.2.1 and it works :-) Thanks! Good. I'll push it into 3.2.2. Thanks for tracking that down. Many other flag handling cases like that have already been fixed, but evidently not that one. J |