On 2025-Oct-22, Tom Lane wrote:
> Interesting. I also realized, after re-reading the snippet I showed,
> that gcc is treating the code leading up to a CALL instruction as a
> separate basic block from the code following the CALL. So that begs
> the question of which count is shown for the functi
Jacob Champion writes:
> (I don't know the answer to this question, but I will note that clang
> (15.0.7) does not seem to make this mistake on my machine, and reports
> a call count of zero for the `return` on line 1495. Looking at the
> disassembly, it seems to add more instrumentation points th
On Tue, Oct 21, 2025 at 11:11 PM Hayato Kuroda (Fujitsu)
wrote:
> Per above, I could consider in pguotput.c., line 1495 was actually executed
> but
> 1503 was counted when it reached line 1494. Another question is why one of the
> branch was reported as 100% and another one was 0%. Is it just bec
Dear Álvaro, Tom,
Thanks for giving some low-layer information. I understood like:
gcov does not actually count each line, counts a chunk of codes. Boundaries are
not same as code paths, before-and-after the if {} can be in the same chunk.
Per above, I could consider in pguotput.c., line 1495 was
=?utf-8?Q?=C3=81lvaro?= Herrera 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 gen
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?
make -C backend/replication/pgoutput all
make[2]: Entering directory
'/home/coverage/pgsrc/pgsql/src/backend/replicatio
On Fri, Oct 17, 2025 at 2:15 PM Álvaro Herrera wrote:
> Hmm, these reports are supposed to have been generated with -O0. This
> is the configure line:
>
> ./configure --cache-file=/home/coverage/pgsrc/configure.cache --enable-depend
> --enable-coverage --enable-tap-tests --enable-nls --with-pyth
Dear hackers,
While investigating the code coverage I found the questionable report. Do you
have
any theories around here?
Attached file is the code coverage report in pgoutput.c, generated by gcov. In
pgoutput_change(), I found that the branch seems not to be chosen but counted.
```
183433:
Dear Steven,
> I noticed another weird thing in your attached log. The line 1506 and 1509
> should be executed
> the same number of times. But line 1506 was executed one more time than line
> 1509.
> Maybe a bug of gcov?
Oh, I didn't notice. Yeah it was also strange. Is there a possibility th
returned 100%
-: 1507:
-: 1508: /* First check the table filter */
183432: 1509: switch (action)
Thanks,
Steven
From: Hayato Kuroda (Fujitsu)
Sent: Friday, October 17, 2025 11:40
To: '[email protected]'
Subject: Qu
On 2025-Oct-17, Jacob Champion wrote:
> On Fri, Oct 17, 2025 at 3:55 AM Hayato Kuroda (Fujitsu)
> wrote:
> > Oh, I didn't notice. Yeah it was also strange. Is there a
> > possibility that complier optimization did prefetch and it was also
> > counted?
>
> FWIW, I'm used to having to set -O0 for
On Fri, Oct 17, 2025 at 3:55 AM Hayato Kuroda (Fujitsu)
wrote:
> Oh, I didn't notice. Yeah it was also strange. Is there a possibility that
> complier optimization
> did prefetch and it was also counted?
FWIW, I'm used to having to set -O0 for the best coverage behavior.
-Og _usually_ works fine
12 matches
Mail list logo
