Re: Bogus reports from coverage.postgresql.org
От | Tom Lane |
---|---|
Тема | Re: Bogus reports from coverage.postgresql.org |
Дата | |
Msg-id | 12595.1521057160@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Bogus reports from coverage.postgresql.org (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Bogus reports from coverage.postgresql.org
|
Список | pgsql-www |
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
В списке pgsql-www по дате отправления: