From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
cc: Alvaro Herrera <alvherre@alvh.no-ip.org>,
        Stephen Frost <sfrost@snowman.net>,
        Magnus Hagander <magnus@hagander.net>,
        PostgreSQL WWW <pgsql-www@lists.postgresql.org>
Subject: Re: Bogus reports from coverage.postgresql.org
In-reply-to: <6735.1521045999@sss.pgh.pa.us>
References: <20180314154352.ao4psdohgxd4pw65@alvherre.pgsql>
 <4710.1521044117@sss.pgh.pa.us> <5744.1521045105@sss.pgh.pa.us>
 <6735.1521045999@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Wed, 14 Mar 2018 12:46:39 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <12594.1521057160.1@sss.pgh.pa.us>
Date: Wed, 14 Mar 2018 15:52:40 -0400
Message-ID: <12595.1521057160@sss.pgh.pa.us>
Precedence: bulk

I wrote:
> I'm still a bit suspicious that we may have a process problem,
> but it's looking like there may be grounds for an lcov bug
> report.

Well, this is darn interesting.  I got the Fedora lcov maintainer
to push an update absorbing the upstream "gcc 8" fixes.  (Turned
out he'd already done that for rawhide, but forgot to push it into
the F28 branch.)  And with that, and gcc 8.0.1, ... no bug.  The
lines are marked "lineNoCov" with or without lcov_branch_coverage.

The commit message for said upstream patch is even more interesting:

    Subject: [PATCH] geninfo: Add gcc 8 support
    
    Fix errors and incorrect data when trying to collect coverage data
    for programs compiled with gcc 8.
    
    Covers the following gcov-related changes in gcc:
    
    .gcov-file format:
      - Line coverage data can appear multiple times for the same line
      - Line coverage count can be suffixed by '*' to indicated unexecuted
        basic blocks in that line
    
    .gcno-file format:
      - new header field 'support unexecuted blocks flag'
      - new function record fields 'column number', 'ending line number',
        and 'compiler-generated entity flag'

Perhaps I'm reading too much into this, but what it sounds like is
that gcc's coverage data output format was incapable of correctly
representing the situation before gcc 8, and thus that it's not
really lcov's fault that we get questionable output.

			regards, tom lane