-
Notifications
You must be signed in to change notification settings - Fork 12k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Malformed MC/DC Coverage record with macro definitions #77871
Comments
I think an easy workaround is to replace StartLoc for MC/DC branches and decisions ( |
I've got a fix for this; just testing it a bit more. I should have the PR hopefully tomorrow. |
…egion. This fixes MC/DC issue llvm#77871 in which branches under ExpansionRegions were not being included in the creation of the MC/DC record. The fix is a slight refactor in how branches associated with an MCDCDecisionRegion are gathered such that ExpansionRegions can be scanned recursively.
…egion. This fixes MC/DC issue llvm#77871 in which branches under ExpansionRegions were not being included in the creation of the MC/DC record. The fix is a slight refactor in how branches associated with an MCDCDecisionRegion are gathered such that ExpansionRegions can be scanned recursively.
To summarize the problem: #78819 tries to scan forward to collect all #78969 tries to scan backward to find the associated I agree that #78969 is preferred. Note: if we can avoid stable_sort in |
Yet another interesting case (https://godbolt.org/z/hzeqoGcd8)
|
The current implementation (D138849) assumes `Branch`(es) would follow after the corresponding `Decision`. It is not true if `Branch`(es) are forwarded to expanded file ID. As a result, consecutive `Decision`(s) would be confused with insufficient number of `Branch`(es). `Expansion` will point `Branch`(es) in other file IDs if `Expansion` is included in the range of `Decision`. Fixes #77871 --------- Co-authored-by: Alan Phipps <a-phipps@ti.com>
To relax scanning record, tweak order by `Decision < Expansion`, or `Expansion` could not be distinguished whether it belonged to `Decision` or not. Relevant to llvm#77871 (cherry picked from commit 438fe1d)
The current implementation (D138849) assumes `Branch`(es) would follow after the corresponding `Decision`. It is not true if `Branch`(es) are forwarded to expanded file ID. As a result, consecutive `Decision`(s) would be confused with insufficient number of `Branch`(es). `Expansion` will point `Branch`(es) in other file IDs if `Expansion` is included in the range of `Decision`. Fixes llvm#77871 --------- Co-authored-by: Alan Phipps <a-phipps@ti.com> (cherry picked from commit d912f1f)
/pull-request #80513 |
The PR has been created so we will track status there. |
To relax scanning record, tweak order by `Decision < Expansion`, or `Expansion` could not be distinguished whether it belonged to `Decision` or not. Relevant to llvm#77871 (cherry picked from commit 438fe1d)
The current implementation (D138849) assumes `Branch`(es) would follow after the corresponding `Decision`. It is not true if `Branch`(es) are forwarded to expanded file ID. As a result, consecutive `Decision`(s) would be confused with insufficient number of `Branch`(es). `Expansion` will point `Branch`(es) in other file IDs if `Expansion` is included in the range of `Decision`. Fixes llvm#77871 --------- Co-authored-by: Alan Phipps <a-phipps@ti.com> (cherry picked from commit d912f1f)
To relax scanning record, tweak order by `Decision < Expansion`, or `Expansion` could not be distinguished whether it belonged to `Decision` or not. Relevant to llvm#77871
The current implementation (D138849) assumes `Branch`(es) would follow after the corresponding `Decision`. It is not true if `Branch`(es) are forwarded to expanded file ID. As a result, consecutive `Decision`(s) would be confused with insufficient number of `Branch`(es). `Expansion` will point `Branch`(es) in other file IDs if `Expansion` is included in the range of `Decision`. Fixes llvm#77871 --------- Co-authored-by: Alan Phipps <a-phipps@ti.com>
To relax scanning record, tweak order by `Decision < Expansion`, or `Expansion` could not be distinguished whether it belonged to `Decision` or not. Relevant to llvm#77871 (cherry picked from commit 438fe1d)
The current implementation (D138849) assumes `Branch`(es) would follow after the corresponding `Decision`. It is not true if `Branch`(es) are forwarded to expanded file ID. As a result, consecutive `Decision`(s) would be confused with insufficient number of `Branch`(es). `Expansion` will point `Branch`(es) in other file IDs if `Expansion` is included in the range of `Decision`. Fixes llvm#77871 --------- Co-authored-by: Alan Phipps <a-phipps@ti.com> (cherry picked from commit d912f1f)
To relax scanning record, tweak order by `Decision < Expansion`, or `Expansion` could not be distinguished whether it belonged to `Decision` or not. Relevant to llvm#77871 (cherry picked from commit 438fe1d)
The current implementation (D138849) assumes `Branch`(es) would follow after the corresponding `Decision`. It is not true if `Branch`(es) are forwarded to expanded file ID. As a result, consecutive `Decision`(s) would be confused with insufficient number of `Branch`(es). `Expansion` will point `Branch`(es) in other file IDs if `Expansion` is included in the range of `Decision`. Fixes llvm#77871 --------- Co-authored-by: Alan Phipps <a-phipps@ti.com> (cherry picked from commit d912f1f)
To relax scanning record, tweak order by `Decision < Expansion`, or `Expansion` could not be distinguished whether it belonged to `Decision` or not. Relevant to llvm#77871 (cherry picked from commit 438fe1d)
The current implementation (D138849) assumes `Branch`(es) would follow after the corresponding `Decision`. It is not true if `Branch`(es) are forwarded to expanded file ID. As a result, consecutive `Decision`(s) would be confused with insufficient number of `Branch`(es). `Expansion` will point `Branch`(es) in other file IDs if `Expansion` is included in the range of `Decision`. Fixes llvm#77871 --------- Co-authored-by: Alan Phipps <a-phipps@ti.com> (cherry picked from commit d912f1f)
To relax scanning record, tweak order by `Decision < Expansion`, or `Expansion` could not be distinguished whether it belonged to `Decision` or not. Relevant to llvm#77871 (cherry picked from commit 438fe1d)
The current implementation (D138849) assumes `Branch`(es) would follow after the corresponding `Decision`. It is not true if `Branch`(es) are forwarded to expanded file ID. As a result, consecutive `Decision`(s) would be confused with insufficient number of `Branch`(es). `Expansion` will point `Branch`(es) in other file IDs if `Expansion` is included in the range of `Decision`. Fixes llvm#77871 --------- Co-authored-by: Alan Phipps <a-phipps@ti.com> (cherry picked from commit d912f1f)
Clang -fcoverage-mcdc emits malformed records to crash llvm-cov with
assert(NumConds == 0);
if:Reproducible code (https://godbolt.org/z/xMGPafdvG)
Unexpected
Branch
order will be seen.("Decision, branch, branch, decision, branch, branch" is expected)
The text was updated successfully, but these errors were encountered: