PR #84797 causes an ICE in some situations #85081
Labels
C-bug
Category: This is a bug.
Comments
richkadel
added a commit
to richkadel/rust
that referenced
this issue
May 8, 2021
Fixes: rust-lang#85081 An `assert!()` in `FunctionCoverage` failed, because PR rust-lang#84797 replaces unreachable `Counter`s with `Unreachable` code regions to be added to the function's coverage map. To fix it, and still generate valid LLVM coverage IR, convert one unreachable to a `Counter`.
This was referenced May 8, 2021
|
Fixed via the revert in PR #85196 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
PR #84797 (Report coverage 0 of dead blocks, merged on May 7, 2021) replaces any MIR
Coveragestatement that is about to be dropped during MIR simplification with aCoverageKind::Unreachablestatement, and adds that statement to theSTART_BLOCK. This makes it possible to still add theCodeRegionsfor the removed (unreachable) code to the coverage map, so they can be reported as unexecuted code.The MIR
InstrumentCoveragepass always adds aCoverageKind::Counterto theSTART_BLOCK(so if a function is called, it is counted), and I assumed that theSTART_BLOCKitself could never be simplified away.However, when compiling some complex async and executor constructions from a large code base, the compiler ICE'd, and I was able to determine that some kind of MIR transform can drop the
START_BLOCK, and can generate a final MIR that has allCoverageKind::Counterstatements replaced withCoverageKind::Unreachablestatements.The ICE is caused now when a function has
CoverageKind::Unreachablestatements and noCoverageKind::Counter. At least oneCoverageKind::Counteris required, to set the function hash for LLVM InstrProf, and anassert!()fails when generating the coverage map (for the unreachable regions) without this function hash.A PR that fixes this issue has been uploaded (#85082).
The text was updated successfully, but these errors were encountered: