=?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de> writes:
> On 2025-Oct-21, Jacob Champion wrote:
>> Are you able to double-check the compiler invocation for pgoutput.c?
> Yep -- it does get -O0. Is there some other flag this is missing?
I think this is probably a gcc artifact. I looked at the assembly
code generated in coverage mode, which on my setup is like
$ gcc -std=gnu11 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Wendif-labels
-Wmissing-format-attribute-Wimplicit-fallthrough=3 -Wcast-function-type -Wshadow=compatible-local -Wformat-security
-fno-strict-aliasing-fwrapv -fexcess-precision=standard -Wno-format-truncation -Wno-stringop-truncation -g -O0
-fprofile-arcs-ftest-coverage -fPIC -fvisibility=hidden -I../../../../src/include -D_GNU_SOURCE -S pgoutput.c
In pgoutput.s I find
.loc 9 1494 7
movq -120(%rbp), %rax
movq %rax, %rdi
call is_publishable_relation@PLT
movl %eax, %edx
# this is evidently incrementing the count for line 1494:
movq 8+__gcov0.pgoutput_change(%rip), %rax
addq $1, %rax
movq %rax, 8+__gcov0.pgoutput_change(%rip)
.loc 9 1494 6
movl %edx, %eax
xorl $1, %eax
.loc 9 1494 5
testb %al, %al
je .L275
# this is evidently incrementing the count for line 1495:
movq 16+__gcov0.pgoutput_change(%rip), %rax
addq $1, %rax
movq %rax, 16+__gcov0.pgoutput_change(%rip)
.loc 9 1495 3
jmp .L274
.L275:
.loc 9 1503 10
movq -40(%rbp), %rax
movzbl 24(%rax), %eax
.loc 9 1503 5
testb %al, %al
je .L277
# this is evidently incrementing the count for line 1504:
movq 24+__gcov0.pgoutput_change(%rip), %rax
addq $1, %rax
movq %rax, 24+__gcov0.pgoutput_change(%rip)
.loc 9 1504 15
movq -128(%rbp), %rax
movq 16(%rax), %rax
.loc 9 1504 7
movl 4(%rax), %eax
movl %eax, -4(%rbp)
.L277:
.loc 9 1506 13
movq -120(%rbp), %rdx
movq -40(%rbp), %rax
movq %rdx, %rsi
movq %rax, %rdi
call get_rel_sync_entry
movq %rax, -56(%rbp)
# this is evidently incrementing the count for line 1506:
movq 32+__gcov0.pgoutput_change(%rip), %rax
addq $1, %rax
movq %rax, 32+__gcov0.pgoutput_change(%rip)
So what I am seeing is that there is not actually a separate counter
for line 1503. It must be that gcov is told that's part of the same
basic block as line 1494 and should be displayed with the same count.
Another thing that I had not known before is that the count associated
with a function-call line is incremented after return, so that no
count will accrue if the function is called but throws an error.
Now, I'm sure Alvaro's machine is using a different gcc version, and
maybe it doesn't act exactly like this. But I think essentially what
is happening is that there is only one counter for each chunk of code
that the compiler regards as a basic block, and the block boundaries
are not as intuitive as you might think.
regards, tom lane
