================ Comment at: test/CoverageMapping/break.c:3 @@ +2,3 @@ +// RUN: %clang %s -fprofile-instr-generate -fcoverage-mapping -O2 -o %t/test +// RUN: (cd %t; %t/test) +// RUN: llvm-profdata merge %t/default.profraw -o %t/pgodata ---------------- Alex Lorenz wrote: > Alex Lorenz wrote: > > Reid Kleckner wrote: > > > Alex Lorenz wrote: > > > > Reid Kleckner wrote: > > > > > I don't think we allow execution tests in Clang's internal test > > > > > suite. Can this live in test-suite? > > > > I can take out the execution part then, so it will look something like > > > > this: > > > > > > > > // RUN: %clang %s -fprofile-instr-generate -fcoverage-mapping -O2 -o > > > > %stest > > > > // RUN: llvm-cov dump %stest| FileCheck %s > > > Even this test would rely on having a system linker that can link a > > > binary for LLVM_DEFAULT_TARGET_TRIPLE, which might not be a native > > > architecture. Can llvm-cov -dump run on an object file? Is that a useful > > > test? > > > > > > This kind of large execution test for coverage seems valuable, but I > > > don't think we can reasonably expect it to pass in every supported > > > configuration. It seems to me like it's a better fit for test-suite. We > > > can definitely keep the IRGen tests, though. > > I see your point. In that case I can just compile and create an object > > file, and llvm-cov should be able to dump the info from it as long as > > LLVM's object file API's support the object file format. This would be a > > useful test indeed, as I'm looking at the mapping regions produced by clang > > and the execution counts don't matter. > The object file tests will work with slight modifications to the coverage > reader code. > > As a result of that the tests will use: > > RUN: %clang %s -c -fprofile-instr-generate -fcoverage-mapping -o %stest > RUN: llvm-cov dump %stest | FileCheck %s Another thing that I can do is to add an option to clang to dump the coverage mapping info instead of relying on a separate tool. Something like "clang -cc1 -dump-coverage-mapping". This might be an even better approach.
http://reviews.llvm.org/D4793 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
