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 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
Hi, Hayato,
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?
183433: 1506: relentry = get_rel_sync_entry(data, relation);
call0 returne
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
11 matches
Mail list logo
