Change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I have a large-ish project with ~6000 testcases, and for a long time now, code coverage has been hit-or-miss. The issue is that some of the test cases don't seem to get their data included in the files, and so don't show up as having an effect on coverage. The unrecorded tests seem to be essentially random, but with thousands of tests, single-digit-percentage failures are noticed on every test run. It's been annoying. So I finally sat down to try and reduce to a simplest error, but it still takes multiple files, so is difficult to include inline in a GitHub issue. The tree: When I run a test via: which shows 2 tests run: Then report on that particular function via: Most of the time, I see the correct result: But sometimes (about 1 in 170 times), I see this: It seems to be related to having multiple source files; I could not get similar behavior with only a . I've seen the problem appear on both MacOS (Mohave) and on Windows (in Windows Subsystem for Linux 2) The two-source-file tree mentioned up above (including the script I run to repeat the test until a failure happens), is on a bug-report branch here: This really feels like whichever thread is controlling writes to the file is missing messages. Queue overrun maybe? (I haven't looked.) <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --:
label A-code-coverage
I see you are using the placeholder for the profile file, which talks about locking and merging these files at runtime. Maybe adding the PID placeholder as well might avoid conflicts here. Can you give that a try?
Gave it a try; still exhibits the same behavior.
is definitely an indication to "please merge"; and doesn't do that, but is really about processes, not threads. I suspect whatever is doing the merging of thread data is what's got the issue here. (Though I get the same effect when I tell the test runner to just use one thread, as well.)
Just learned that the option of is not the same thing as (which sends that flag to the test-runner). Adding to my harness removes the intermittent results. Not closing this issue, though. Rust is supposed to be "fearless concurrency" so this should work correctly even if the test runner is using multiple threads.
Still reproducible with I used such script to run against , because of I can not find : at step 854, coverage changed from 4 to 2.
This is in cargo-binutils.
I created bug against upstream llvm/llvm-project
Looks like this is not llvm bug. There is bool flag , that is by default, and depend on it llvm generates different code: So if set it to true via option , then C++ variant of test is unable to reproduce problem. So is any way to set via rustc command line?
or another atomic-counter flag may work, but I have not tested it yet.
I can not see how any of this options can reach here . So I create PR to set to by default.
Looks like should also works. where

Discussion:
if (InstrProfileOutput) { Options.InstrProfileOutput = InstrProfileOutput; } <ins> // cargo run tests in multhreading mode by default // so use atomics for coverage counters Options.Atomic = true; </ins> MPM.addPass(InstrProfiling(Options, false)); } );

CHECK:        [[DEFINE_INTERNAL]] { {{.*}} } @_R{{[a-zA-Z0-9_]+}}testprog14will_be_called() unnamed_addr #{{[0-9]+}} { CHECK-NEXT:   start: CHECK-NOT:    [[DEFINE_INTERNAL]] <del> CHECK:        %pgocount = load i64, {{i64*|ptr}} </del> <ins> CHECK:        atomicrmw add ptr </ins> CHECK-SAME:   @__profc__R{{[a-zA-Z0-9_]+}}testprog14will_be_called, CHECK:        declare void @llvm.instrprof.increment({{i8*|ptr}}, i64, i32, i32) #[[LLVM_INSTRPROF_INCREMENT_ATTR:[0-9]+]]