https://bugs.kde.org/show_bug.cgi?id=472329
--- Comment #6 from Paul Floyd <pjfl...@wanadoo.fr> ---
Getting back to the problem
if (f && *f != a) {
generates
movq 40(%rbx), %rax # MEM <type> [(struct pair *)range$_M_node_264
+ 40B], SR.252
Error on next line:
cmpq %r14, %rax # f, SR.252
je .L47 #,
cmpb $0, -97(%rbp) #, %sfp
jne .L69 #,
g++ has reversed the order of the checks.
Valgrind's detection of this reversal first of all does some filtering of
statements that preclude such ordering.
One such statement is the load, which can potentially trap. In this case, if I
understand correctly, Valgrind sees the read from 40(%rbx), sees that as
potentially trapping and thus precludes it from transforming the expression
back to a bit-and.
So two questions:
Why is GCC going this transfomation.
If the transformation is valid, how to add 'safe' loads to the guarded
expression / bit-and transformation of VEX.
--
You are receiving this mail because:
You are watching all bug changes.
