Fix issue with overlapping basic blocks - #513
Open
rlalik wants to merge 1 commit into
Open
Conversation
Collaborator
|
There are a few issues with this PR:
I'm also curious what you see with your actual testcase, if you run with LLVM rather than gcc - if you see similar location issues, and if you see similar issues with both the 'gcov' and 'profdata' paths. Thanks for your contribution! Henry |
Author
|
Thanks for feedback, I'll look into that. About the tests, I realized that many of the tests were failing already after I made fork. For example: For example first on the list This is not related to my changes. Do you think you can fix the tests before I go with mine? |
rlalik
force-pushed
the
fix_start_line_issue
branch
from
July 22, 2026 13:39
bf634cd to
50401f4
Compare
Collaborator
|
From the actions tab - we see that the regressions all seem to pass before this change - so the situation might be a bit more complicated. What happens when you run them locally? |
Author
|
I updated the fork and rebased the code, now, locally, only |
Author
|
I also created some simple test to test the modification. It works with gcc, g++, clang, clang++. The commit is here: master...rlalik:lcov:multiple_basic_blocks_tests Here is the test result: If you wish, I could add this commit to this PR. BTW, I also run simialr compiler-dependent test on the main test suite with following results. Perhaps on could work on having the tests also working for LLVM? As some of the tests are completely compiler-independent, the test suite could be separated into compiler-dependent and compiler-independent, and the latter one run once, and the former one for separate compilers? I could open separate issue for this if you like. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Following discussion #468 and my problem with inconsistent data, I would like propose this approach to the problem.
Starting from the source of the problem:
what happens is that, gtest macro
TEST()(and perhapsTEST_F()- didn't test it) creates a class object, with constructor, destructor and*_TestBody()function, which all occupy the same line in the source code, see for example this report from gcov:In my solutions, I introduced a new error
ERROR_MUTIPLE_BASIC_BLOCKSwhich is set when the second and the next function is created at the same start line. The error is of a type ofignorable_warningthus is not fatal, and should be not.Here is the output for the same case like above: