[Bug gcov-profile/105238] Regression: using -fprofile-dir: gcno files not ccache cachable anymore / gcovr report broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105238 Richard Biener changed: What|Removed |Added Target Milestone|14.0|14.2 --- Comment #9 from Richard Biener --- GCC 14.1 is being released, retargeting bugs to GCC 14.2.
[Bug gcov-profile/105238] Regression: using -fprofile-dir: gcno files not ccache cachable anymore / gcovr report broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105238 Martin Liška changed: What|Removed |Added Target Milestone|--- |14.0
[Bug gcov-profile/105238] Regression: using -fprofile-dir: gcno files not ccache cachable anymore / gcovr report broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105238 Martin Liška changed: What|Removed |Added Keywords||patch --- Comment #8 from Martin Liška --- Patch candidate has been sent: https://gcc.gnu.org/pipermail/gcc-patches/2023-April/615048.html
[Bug gcov-profile/105238] Regression: using -fprofile-dir: gcno files not ccache cachable anymore / gcovr report broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105238 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org
[Bug gcov-profile/105238] Regression: using -fprofile-dir: gcno files not ccache cachable anymore / gcovr report broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105238 --- Comment #7 from Esger Abbink --- Building a real project with the patched gcc9.4 and ccache 4.5.1 (replacing -fprofile-dir with -fprofile-prefix-map=${CMAKE_SOURCE_DIR}=.) it looks ok at first sight: - 100% cache hits for the second compilation in a different directory - gcda created next to .o & .gcda for both first and second compilations/directories However when running the unittests binaries there are quite a number of gcov warnings: [==] 2807 tests from 297 test suites ran. (272928 ms total) [ PASSED ] 2807 tests. libgcov profiling error: :overwriting an existing profile data with a different timestamp libgcov profiling error:#:overwriting an existing profile data with a different timestamp libgcov profiling error: :overwriting an existing profile data with a different timestamp libgcov profiling error::overwriting an existing profile data with a different timestamp libgcov profiling error::overwriting an existing profile data with a different timestamp libgcov profiling error:#:overwriting an existing profile data with a different timestamp libgcov profiling error:&:overwriting an existing profile data with a different timestamp libgcov profiling error:#:overwriting an existing profile data with a different timestamp libgcov profiling error:#:overwriting an existing profile data with a different timestamp libgcov profiling error:':overwriting an existing profile data with a different timestamp profiling::Cannot open libgcov profiling error:#:overwriting an existing profile data with a different timestamp libgcov profiling error:#:overwriting an existing profile data with a different timestamp libgcov profiling error::overwriting an existing profile data with a different timestamp ... [this continues for quite a number of lines] Note that these warnings are produced both for the directory where compilation really took place as for the directory where .o & .gcno were taken from the cache. Since the gcda files are created next to the .o * .gcno there should not be any name clashes (for identical names the path would still be different). So I am not sure what is happening here? Unfortunately, the warning lines do not include any information about which file is being written or which file is clashing. Still, gcovr is able to produce a coverage report with information that looks sane, but there are differences with the gcc7.5 reports. I would assume because of the above warnings. The coverage report for the second compilation (using cached .o & .gcno) is for all intents and purposes the same as the one for the first compilation. The difference being 2 lines and 2 branches on totals of 17515 and 14727.
[Bug gcov-profile/105238] Regression: using -fprofile-dir: gcno files not ccache cachable anymore / gcovr report broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105238 --- Comment #6 from Esger Abbink --- After patching ccache 4.5.1 to understand -fprofile-prefix-map it does cache .o and .gcno: $ ccache -z -C $ cd /home/esger/src/application/coverage_test/dir1/source/ && CCACHE_DEBUG= CCACHE_BASEDIR=/home/esger/src/application/coverage_test/dir1 ccache /usr/bin/g++-9.4p --coverage -fprofile-prefix-map=/home/esger/src/application/coverage_test/dir1=. -fdebug-prefix-map=/home/esger/src/application/coverage_test/dir1=. -c /home/esger/src/application/coverage_test/dir1/source/main.cpp $ ccache -s Summary: Hits: 0 /1 (0.00 %) Direct: 0 /1 (0.00 %) Preprocessed: 0 /1 (0.00 %) Misses: 1 Direct: 1 Preprocessed: 1 Primary storage: Hits: 0 /2 (0.00 %) Misses: 2 Cache size (GB): 0.00 / 5.00 (0.00 %) Cleanups: 4 $ cd /home/esger/src/application/coverage_test/dir2/source/ && CCACHE_DEBUG= CCACHE_BASEDIR=/home/esger/src/application/coverage_test/dir2 ccache /usr/bin/g++-9.4p --coverage -fprofile-prefix-map=/home/esger/src/application/coverage_test/dir2=. -fdebug-prefix-map=/home/esger/src/application/coverage_test/dir2=. -c /home/esger/src/application/coverage_test/dir2/source/main.cpp $ ccache -s Summary: Hits: 1 /2 (50.00 %) Direct: 1 /2 (50.00 %) Preprocessed: 0 /1 (0.00 %) Misses: 1 Direct: 1 Preprocessed: 1 Primary storage: Hits: 2 /4 (50.00 %) Misses: 2 Cache size (GB): 0.00 / 5.00 (0.00 %) Cleanups: 4 Using the cached .o/.gcno also generates a gcda in the correct location: $ cd /home/esger/src/application/coverage_test/dir2/source/ && CCACHE_DEBUG= CCACHE_BASEDIR=/home/esger/src/application/coverage_test/dir2 ccache /usr/bin/g++-9.4p --coverage -fprofile-prefix-map=/home/esger/src/application/coverage_test/dir2=. -fdebug-prefix-map=/home/esger/src/application/coverage_test/dir2=. main.o -o ../bin/a.out $ cd /home/esger/src/application/coverage_test/dir2 && ./bin/a.out $ ls source/ main.cpp main.gcda main.gcno main.o $ gcovr --html coverage.html . [ coverage report OK ] Though the gcno of source still contains a wrong CWD: $ gcov-dump-9.4p source/main.gcno |more main.gcno:note:magic `gcno':version `A94*' main.gcno:stamp 761679940 main.gcno:cwd: /home/esger/src/application/coverage_test/dir1/source main.gcno: 0100: 20:FUNCTION ident=1826217343, lineno_checksum=0x36a9d8e5, cfg_checksum=0xc0bbb23e, `_GLOBAL__sub_I__Z5funcAi' main.cpp:21:1-21:1, artificial main.gcno:0141: 1:BLOCKS 4 blocks main.gcno:0143: 3:ARCS 1 arcs main.gcno:0143: 5:ARCS 2 arcs main.gcno:0143: 3:ARCS 1 arcs main.gcno:0145: 9:LINES main.gcno:0145: 9:LINES ... Not sure though what (negative) impact that will/could have?
[Bug gcov-profile/105238] Regression: using -fprofile-dir: gcno files not ccache cachable anymore / gcovr report broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105238 --- Comment #5 from Esger Abbink --- Cherry picking https://github.com/gcc-mirror/gcc/commit/cde87638bf5cf6aafffb590986b6a890da0ba06c on top of releases-9.4.0 allowed me to apply the patch to get a patched gcc9.4 supporting -fprofile-prefix-map and that leads to the same (desired) behavior as described in the previous comment for patched gcc11, plus gcovr is now able to produce coverage reports. However, all is still not well, because ccache does not know the -fprofile-prefix-map option and therefore marks files compiled with it as uncacheable.. :(
[Bug gcov-profile/105238] Regression: using -fprofile-dir: gcno files not ccache cachable anymore / gcovr report broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105238 --- Comment #4 from Esger Abbink --- We use Ubuntu 20.04 currently for our jenkins images. With gcc built from master with patch using -fprofile-prefix-map works as expected: with a main.cpp in /home/esger/src/application/coverage_test/dir1/source compiling with: cd /home/esger/src/application/coverage_test/dir1/source/ && g++-11 --coverage -fprofile-prefix-map=/home/esger/src/application/coverage_test/dir1=dir2 -c /home/esger/src/application/coverage_test/dir1/source/main.cpp cd /home/esger/src/application/coverage_test/dir1/source/ && g++-11 --coverage -fprofile-prefix-map=/home/esger/src/application/coverage_test/dir1=dir2 main.o -o ../bin/a.out results in a main.gcno in the source directory, and after running ./dir1/bin/a.out from /home/esger/src/application/coverage_test there is a main.gcda (non-mangled) in dir2/source. Note that I was not able to produce a meaningful coverage report even for the simplest/first case of the four above with gcc 11. I think gcovr might not yet support newer formats used? So I can't currently verify if with -fprofile-prefix-map the coverage report is ok, but I would assume so. (Still, I don't quite understand why behavior that was working is now broken/changed and needs a new option? ie. why is -fprofile-dir mangling the name, and -fprofile-prefix-map not? and 9.4 behavior with -fprofile-dir still seems broken when explicitly specifying the default?) If I perform a small experiment more closely resembling what cmake + ccache do: cd /home/esger/src/application/coverage_test/dir1/source/ && CCACHE_BASEDIR=/home/esger/src/application/coverage_test/dir1 ccache /usr/bin/g++-11 --coverage -fprofile-prefix-map=/home/esger/src/application/coverage_test/dir1=. -fdebug-prefix-map=/home/esger/src/application/coverage_test/dir1=. -c /home/esger/src/application/coverage_test/dir1/source/main.cpp cd /home/esger/src/application/coverage_test/dir1/source/ && CCACHE_BASEDIR=/home/esger/src/application/coverage_test/dir1 ccache /usr/bin/g++-11 --coverage -fprofile-prefix-map=/home/esger/src/application/coverage_test/dir1=. -fdebug-prefix-map=/home/esger/src/application/coverage_test/dir1=. main.o -o ../bin/a.out and then from /home/esger/src/application/coverage_test/dir2 run ../dir1/bin/a.out (to simulate a run with a binary built from cached .o and .gcno run from a different directory) again the gcda is created in the dir2/source directory with a non-mangled name. yey :) I can also see the source file paths in the gcno are relative: main.gcno:note:magic `gcno':version `B20 ' main.gcno:stamp 625107654 main.gcno:checksum 0 main.gcno:cwd: /home/esger/src/application/coverage_test/dir1/source main.gcno: 0100: 83:FUNCTION ident=1482908279, lineno_checksum=0x2c72f060, cfg_checksum=0xc0bbb23e, `_GLOBAL__sub_I__Z5funcAi' ./source/main.cpp:21:1-21:1, artificial main.gcno:0141: 4:BLOCKS 4 blocks main.gcno:0143: 12:ARCS 1 arcs main.gcno:0143: 20:ARCS 2 arcs main.gcno:0143: 12:ARCS 1 arcs main.gcno:0145: 42:LINES main.gcno:0145: 42:LINES ... So with a patched gcc11, dropping -fprofile-dir and using -fprofile-prefix-map instead, gcda creation seems ok. The gcno files seem to contain relative paths to the source file too. However, the gcno file also still contains the compilation CWD which interferes with caching it and re-using it for different build dirs. Is there any way to get rid of that? And of course I still need to verify such created gcda files will actually result in a proper coverage report. Applying the patch to 9.4 or 10.3 as vit9696 did should allow me to test that. Will try that tomorrow if I have time.
[Bug gcov-profile/105238] Regression: using -fprofile-dir: gcno files not ccache cachable anymore / gcovr report broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105238 --- Comment #3 from Martin Liška --- > I am happy to test the patch, but not quite sure how to proceed. I would recommend building the current master (or you can wait for a couple of weeks and apply it on the top of GCC 12.1 release that will happen soonish). What distro do you use?
[Bug gcov-profile/105238] Regression: using -fprofile-dir: gcno files not ccache cachable anymore / gcovr report broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105238 --- Comment #2 from Esger Abbink --- There certainly is overlap yes, in particular: "(a) build directory relative paths were stored as the .gcda paths (/a/b/c/master/path/to/file.gcda becomes path/to/file.gcda)" from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063#c8 is exactly what we want (without mangling). Where the build directory would then be /home/esger/src/application in the situation described above. I am happy to test the patch, but not quite sure how to proceed. -fprofile-prefix-map is not a valid option for gcc 9 or 10 as far as I can tell. To which gcc version/branch should I apply the patch? (the other issue mentions a 10.3.x branch, but a clone of the git gcc source does not seem to have such a branch?)
[Bug gcov-profile/105238] Regression: using -fprofile-dir: gcno files not ccache cachable anymore / gcovr report broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105238 Martin Liška changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=105063 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-04-12 --- Comment #1 from Martin Liška --- Thanks for the bug report. I think you described very similar problem to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063. Can you check the suggested patch in the PR, please?