You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This was reported back in 2017 (issue #32849), but apparently it is still an issue. After doing a fair amount of research, it seems this is a problem only with building SHARED libraries, which in this case is a DLL on Windows 10. I do not see this problem when building a STATIC library. I require using a DLL, however, so this is not something I can just ignore.
After the DLL builds, and runs all the tests, it shows the following messages on the console:
[build] =========================================================================================================================================
[build] All tests passed (116189 assertions in 27 test cases)
[build]
[build] warning: 55 functions have mismatched data
[build] warning: 55 functions have mismatched data
[build] [59/59 98% :: 12.421] Install the project...
If it only printed those messages, I could just let this go. The bigger issue, however, is that many of the compiled files are missing from the coverage report. There is a 2-level directory structure inside of an "include" directory, a matching 2-level directory structure inside of a "src" directory. The coverage report only includes the top level of include files (with no files from the subdirectories within the include directory), and also the test files from the "test" directory.
So, in the above directory structure, only the files in include and test were included in the coverage report. When I add the -dump flag to the llvm-cov show call, I do see the 55 entries, all with 0x0 hash values.
Here is an example of the -dump output:
[build] warning: 55 functions have mismatched data
[build] hash-mismatch: No profile record found for '?getCode@HashCoder@@QEAAHXZ' with hash = 0x0
[build] hash-mismatch: No profile record found for '?hashCode@String@@UEBAHXZ' with hash = 0x0
[build] hash-mismatch: No profile record found for '??8String@@UEBA_NAEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z' with hash = 0x0
[build] hash-mismatch: No profile record found for '??0String@@QEAA@PEBD@Z' with hash = 0x0
[build] hash-mismatch: No profile record found for '??0String@@QEAA@PEAD@Z' with hash = 0x0
[build] hash-mismatch: No profile record found for '??4String@@QEAAAEAV0@AEBV0@@Z' with hash = 0x0
[build] hash-mismatch: No profile record found for '??4String@@QEAAAEAV0@AEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z' with hash = 0x0
[build] hash-mismatch: No profile record found for '??4String@@QEAAAEAV0@PEBD@Z' with hash = 0x0
[build] hash-mismatch: No profile record found for '??BString@@QEBA?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@XZ' with hash = 0x0
[build] hash-mismatch: No profile record found for '?begin@String@@QEAA?AUiterator@1@XZ' with hash = 0x0
[build] hash-mismatch: No profile record found for '?end@String@@QEAA?AUiterator@1@XZ' with hash = 0x0
[build] hash-mismatch: No profile record found for '?length@String@@QEBA_KXZ' with hash = 0x0
[build] hash-mismatch: No profile record found for '?empty@String@@QEBA_NXZ' with hash = 0x0
[build] hash-mismatch: No profile record found for '??AString@@QEAAAEAD_K@Z' with hash = 0x0
[build] hash-mismatch: No profile record found for '??AString@@QEBAAEBD_K@Z' with hash = 0x0
I'm not sure what else you want me to provide. In the LLVM instructions for submitting bugs, there was no mention of this type of bug, where it really has nothing to do with the compiler.
The text was updated successfully, but these errors were encountered:
+1 You are not alone, I have am currently facing a similar issue. I can switch to a static build instead of shared build by manually changing the build config. So I can make it work, but this is a fairly big inconvenience for me. I lack the time to investigate it myself.
I am seeing "21 functions have mismatched data" when running llvm-cov against an instrumented DLL. llvm-cov show -dump yields 21 lines like:
hash-mismatch: No profile record found for '?uuid_compare@@YAHQEBE0@Z' with hash = 0x0
I used llvm-profdata to look up those functions and found that a surprising/suspicious number of them actually have the hash 0x0000000000000018 (example below). I'm not sure whether this is relevant or just a strange coincidence.
>llvm-profdata show merged_all.profdata --function ?uuid_compare@@YAHQEBE0@Z
Counters:
?uuid_compare@@YAHQEBE0@Z:
Hash: 0x0000000000000018
Counters: 1
Function count: 3002
Instrumentation level: Front-end
Functions shown: 1
Total functions: 5635
Maximum function count: 1262150269
Maximum internal block count: 261937887
This was reported back in 2017 (issue #32849), but apparently it is still an issue. After doing a fair amount of research, it seems this is a problem only with building SHARED libraries, which in this case is a DLL on Windows 10. I do not see this problem when building a STATIC library. I require using a DLL, however, so this is not something I can just ignore.
After the DLL builds, and runs all the tests, it shows the following messages on the console:
If it only printed those messages, I could just let this go. The bigger issue, however, is that many of the compiled files are missing from the coverage report. There is a 2-level directory structure inside of an "include" directory, a matching 2-level directory structure inside of a "src" directory. The coverage report only includes the top level of include files (with no files from the subdirectories within the include directory), and also the test files from the "test" directory.
So, in the above directory structure, only the files in include and test were included in the coverage report. When I add the -dump flag to the llvm-cov show call, I do see the 55 entries, all with 0x0 hash values.
Here is an example of the -dump output:
I'm not sure what else you want me to provide. In the LLVM instructions for submitting bugs, there was no mention of this type of bug, where it really has nothing to do with the compiler.
The text was updated successfully, but these errors were encountered: