[PATCH] D85036: [llvm-cov] reset executation count to 0 after wrapped segment

Vedant Kumar via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Aug 17 17:11:51 PDT 2020


vsk added a comment.

Hi @zequanwu, we've started seeing a regression due to this change in swift (https://ci.swift.org/view/swift-master-next/job/oss-swift-incremental-RA-osx-master-next/7818/consoleText, see the bit about 'coverage_smoke.swift'). Here's the failure we see:

             165:  165| 2| throw CustomError.Err // CHECK-COV: {{ *}}[[@LINE]]|{{ *}}2
  check:167'0            X~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error: no match found
  check:167'1                                                                          with "@LINE" equal to "167"
  check:167'2                                                                   ?      possible intended match
             166:  166| 2| } catch {
  check:167'0     ~~~~~~~~~~~~~~~~~~
             167:  167| 1| if b { // CHECK-COV: {{ *}}[[@LINE]]|{{ *}}2
  check:167'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
             168:  168| 1| return 1 // CHECK-COV: {{ *}}[[@LINE]]|{{ *}}1
  check:167'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
             169:  169| 1| }

The issue is that line 167 ("if b {") has an execution count of 1, even though it's actually reached twice. Before this change, the wrapped count from the catch block starting on line 166 would apply on line 167, all the way through the IfStmt condition (giving an execution count of 2). But with this change, seeing as the IfStmt condition doesn't get its own region, the line execution count gets picked up from the "Then" side of the IfStmt.

I'm concerned that this nested statements generated in clang as well as swift. Do you have some idea about how to address this?

I wonder whether we can make use of gap regions to fix the clang bugs you were looking at. I noticed that this fixed an issue in instrprof-comdat.h, but it's possible that that was caused by a bug in clang that has since been fixed (per the note).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D85036/new/

https://reviews.llvm.org/D85036



More information about the llvm-commits mailing list