https://bugs.kde.org/show_bug.cgi?id=472329
--- Comment #2 from Paul Floyd <pjfl...@wanadoo.fr> ---
Not easy.
Here is the assembler
# bug472329.cpp:15: auto [a, b]{range->second};
.loc 8 15 30 is_stmt 0 discriminator 1 view .LVU406
movq 40(%rbx), %rax # MEM <type> [(struct pair *)range$_M_node_264
+ 40B], SR.252
.LVL136:
.loc 8 16 5 is_stmt 1 view .LVU407
# bug472329.cpp:16: if (f && *f != a) {
.loc 8 16 11 is_stmt 0 discriminator 1 view .LVU408
Error on next line:
cmpq %r14, %rax # f, SR.252
je .L47 #,
.loc 8 16 11 discriminator 1 view .LVU409
cmpb $0, -97(%rbp) #, %sfp
jne .L69 #,
The corresponding C++
test is a map of bool to pair of int64_t, initialized by a rather contorted
lambda (looks like test code!).
The values are true : {0, 0}
auto range{test.find(true)};
while (range != test.end()) {
auto [a, b]{range->second};
if (f && *f != a) {
range is an std:map::iterator and since it's initialized with the result of a
find for true which is in the map. So the iterator should refer to that one
element.
Next covariants a and b get declared and initialized from the value referred to
by the iterator range. The value is {0, 0} so both a and b are initialized to
zero.
Next there is a check that the variant contains something and if so the
contents are compared to a. Phew!
Back to the assembler. It seems to me that this is performing the tests in the
wrong order. That is
*f != a
then
f
llvm generates
.loc 18 321 22 #
include/c++/v1/optional:321:22
testb %bl, %bl
.Ltmp50:
.loc 17 16 11 # bug472329.cpp:16:11
je .LBB0_19
.Ltmp51:
# %bb.12: # %while.body
# in Loop: Header=BB0_11 Depth=1
#DEBUG_VALUE: foo:f <- [DW_OP_constu 72, DW_OP_minus,
DW_OP_LLVM_fragment 0 64] [$rbp+0]
#DEBUG_VALUE: foo:f <- [DW_OP_LLVM_fragment 64 8] $ebx
#DEBUG_VALUE: foo:range <- $r14
#DEBUG_VALUE: <- [DW_OP_LLVM_fragment 0 64] $rax
cmpq -72(%rbp), %rax # 8-byte Folded Reload
je .LBB0_19
The test of bl looks like checking f and the cmpq at the end comparing *f and
a.
Back to GCC, it looks like
https://archive.fosdem.org/2020/schedule/event/debugging_memcheck_reloaded/attachments/slides/4174/export/events/attachments/debugging_memcheck_reloaded/slides/4174/memcheck_reloaded.pdf
Not sure what the problem is. Maybe the fact that the two operations don't use
the same width, quadword and byte.
--
You are receiving this mail because:
You are watching all bug changes.
