https://bugs.kde.org/show_bug.cgi?id=369509
--- Comment #4 from Julian Seward <jsew...@acm.org> --- (In reply to ahashmi from comment #3) I'll reply about the hwcaps a bit later. Regarding CasCmpNE64: the underlying problem is like this. If the location is not contended (which is almost always the case), then the comparison will compare the same value against itself. If that value is undefined, and we use normal CmpNE64, then Memcheck will complain that we're taking a branch on undefined data, which in fact the program is correct. So it's a false positive. CasCmpNE64 is therefore defined to behave identically to CmpNE64, but provides a hint to Memcheck not to check the definedness of the operands. In that way, the false positive is avoid in the common case that the value is not contended. This is at the cost of not reporting the case where the value is contended and is also undefined. But it seems a small price to pay. > CasCmpNE64(t21,t20) > vex: the `impossible' happened: > iselCondCode Ah, I forgot about that. Given that, from a program-execution viewpoint, it is identical to CmpNE64, just add a "case CasCmpNE64:" at the obvious place in the insn selector. -- You are receiving this mail because: You are watching all bug changes.
