zenithsiz/ftmemsim-valgrind
1
0
Fork 0
mirror of https://github.com/Zenithsiz/ftmemsim-valgrind.git synced 2026-02-04 02:18:37 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

ppc64 --track-origins=yes failure because of bad cmov addHRegUse

Browse Source 
For Pin_CMov getRegUsage_PPCInstr called addHRegUse for the dst
register with HRmWrite, but since this is a conditional move the
register could be both read and written (read + write = modify).
This matches the dst of Pin_FpCMov and Pin_AvCMov.

In a very rare case, and only with --track-origins=yes, this
could cause bad code generation.

This is slightly amazing, this code is from 2005 and as far as
I know we never seen an issue with --track-origins=yes on power
before. And I have been unable to come up simple reproducer.

https://bugs.kde.org/show_bug.cgi?id=449672
This commit is contained in:
Mark Wielaard 2022-02-08 16:36:08 +01:00
parent ab740a1741
commit fb6a77ed78
2 changed files with 2 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
NEWS
View File

@ -63,6 +63,7 @@ are not entered into bugzilla tend to get forgotten about or ignored.
447995 Valgrind segfault on power10 due to hwcap checking code
449483 Powerpc: vcmpgtsq., vcmpgtuq,, vcmpequq. instructions not setting the
condition code correctly.
449672 ppc64 --track-origins=yes failures because of bad cmov addHRegUse
To see details of a given bug, visit
https://bugs.kde.org/show_bug.cgi?id=XXXXXX

2
VEX/priv/host_ppc_defs.c
View File

@ -2590,7 +2590,7 @@ void getRegUsage_PPCInstr ( HRegUsage* u, const PPCInstr* i, Bool mode64 )
return;
case Pin_CMov:
addRegUsage_PPCRI(u, i->Pin.CMov.src);
addHRegUse(u, HRmWrite, i->Pin.CMov.dst);
addHRegUse(u, HRmModify, i->Pin.CMov.dst);
return;
case Pin_Load:
addRegUsage_PPCAMode(u, i->Pin.Load.src);