[Bug lto/104237] [11 Regression] Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute since r11-3126-ga8f9b4c54cc35062
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237 --- Comment #21 from Chengnian Sun --- Thank you, Andrew and Jakub.
[Bug lto/104237] [11 Regression] Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute since r11-3126-ga8f9b4c54cc35062
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237 --- Comment #20 from Jakub Jelinek --- (In reply to Andrew Pinski from comment #19) > (In reply to Chengnian Sun from comment #18) > > Hello folks, > > > > While testing gcc with -fcompare-debug, I was asked a question which puzzled > > me as well. > > > > What if we always enable -g, and use 'strip' to remove debug information > > from the binary file? Then we do not need to pay much attention to bugs > > detected by -fcompare-debug. > > because -g has a compile time overhead and even an assembler time overhead; > in some cases the debugging informationg is huge even for small programs. > Plus there are different levels of -g: -g1, -g2, and -g3 (-g is the same as > -g2). So which one would you enable by default? We could just enable -fvar-tracking-assignments and then just throw that info before var-tracking if -g0. But that would still cause significant IL growth and compile time increase when debug info isn't needed.
[Bug lto/104237] [11 Regression] Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute since r11-3126-ga8f9b4c54cc35062
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237 --- Comment #19 from Andrew Pinski --- (In reply to Chengnian Sun from comment #18) > Hello folks, > > While testing gcc with -fcompare-debug, I was asked a question which puzzled > me as well. > > What if we always enable -g, and use 'strip' to remove debug information > from the binary file? Then we do not need to pay much attention to bugs > detected by -fcompare-debug. because -g has a compile time overhead and even an assembler time overhead; in some cases the debugging informationg is huge even for small programs. Plus there are different levels of -g: -g1, -g2, and -g3 (-g is the same as -g2). So which one would you enable by default?
[Bug lto/104237] [11 Regression] Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute since r11-3126-ga8f9b4c54cc35062
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237 --- Comment #18 from Chengnian Sun --- Hello folks, While testing gcc with -fcompare-debug, I was asked a question which puzzled me as well. What if we always enable -g, and use 'strip' to remove debug information from the binary file? Then we do not need to pay much attention to bugs detected by -fcompare-debug. Thank you. Chengnian.
[Bug lto/104237] [11 Regression] Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute since r11-3126-ga8f9b4c54cc35062
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237 --- Comment #17 from Chengnian Sun --- Thanks for the prompt help. I managed to locate the exact commit.
[Bug lto/104237] [11 Regression] Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute since r11-3126-ga8f9b4c54cc35062
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237 --- Comment #16 from Jakub Jelinek --- -gf4ee27d32 means something didn't work correctly, normally it should be something like r12-6853-gf4ee27d32 which you can use directly in git. Anyway, the git has is after the -g, so f4ee27d32.
[Bug lto/104237] [11 Regression] Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute since r11-3126-ga8f9b4c54cc35062
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237 --- Comment #15 from Andrew Pinski --- The g part of the uuid stands for global revision and the g needs to be removed to get a normal gut hash.
[Bug lto/104237] [11 Regression] Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute since r11-3126-ga8f9b4c54cc35062
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237 --- Comment #14 from Chengnian Sun --- How to interpret the version string of "gcc -v"? For example, in the following output, I tried to locate the commit with id gf4ee27d32, but did not get anything. "gcc version 12.0.1 20220125 (experimental) [master -gf4ee27d32] (GCC)" Thanks. Chengnian.
[Bug lto/104237] [11 Regression] Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute since r11-3126-ga8f9b4c54cc35062
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237 --- Comment #13 from Chengnian Sun --- (In reply to Jakub Jelinek from comment #10) > Because -fcompare-debug tells the driver to compile the TU twice, once > without and once with -gtoggle, and compare the result. > So, if there is a difference in the generated IL e.g. for -flto > -ffat-lto-objects, it will detect it. > Just watch > gcc -flto -O1 pr104237.c -o pr104237 -g -fcompare-debug -v 2>&1 | grep > 'cc1\|lto1' > to see that, cc1 is invoked twice, once without -gtoggle, once with it, but > lto1 is invoked just twice, once for wpa and once for ltrans. > Even if you convince the linker plugin to pass -fcompare-debug even to the > driver that invokes lto1, that would again compare lto1 with and without -g > but only > on a single input (depending on whether the original command line has -g > with or without debug stmts in it). > To reproduce this bug, one needs to do a "manual -fcompare-debug", which is > gcc -flto -O1 pr104237.c -o pr104237 -g // + force lto1 to pass > -fdump-final-insns=1 > gcc -flto -O1 pr104237.c -o pr104237 // + force lto1 to pass > -fdump-final-insns=2 > diff -up 1 2 > Now, in theory the driver could arrange that, but it would only handle the > trivial case when the compilation and linking are from the same command. > Typically with LTO, compilation is done separately and linking is done > separately, and I don't see how the driver could arrange for that to work, > we need in that case two sets of *.o files with the IL, one with -g0 and one > with -g, link twice and compare the result at the end. Thank you so much for the detailed explanation.
[Bug lto/104237] [11 Regression] Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute since r11-3126-ga8f9b4c54cc35062
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Jakub Jelinek --- Fixed for 11.3+ too.
[Bug lto/104237] [11 Regression] Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute since r11-3126-ga8f9b4c54cc35062
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237 --- Comment #11 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:88ff2eb5cc2c1af2ae751c02997d0b5667662782 commit r11-9594-g88ff2eb5cc2c1af2ae751c02997d0b5667662782 Author: Jakub Jelinek Date: Fri Jan 28 11:48:18 2022 +0100 cfgrtl: Fix up locus comparison in unique_locus_on_edge_between_p [PR104237] The testcase in the PR (not included for the testsuite because we don't have an (easy) way to -fcompare-debug LTO, we'd need 2 compilations/linking, one with -g and one with -g0 and -fdump-rtl-final= at the end of lto1 and compare that) has different code generation for -g vs. -g0. The difference appears during expansion, where we have a goto_locus that is at -O0 compared to the INSN_LOCATION of the previous and next insn across an edge. With -g0 the locations are equal and so no nop is added. With -g the locations aren't equal and so a nop is added holding that location. The reason for the different location is in the way how we stream in locations by lto1. We have lto_location_cache::apply_location_cache that is called with some set of expanded locations, qsorts them, creates location_t's for those and remembers the last expanded location. lto_location_cache::input_location_and_block when read in expanded_location is equal to the last expanded location just reuses the last location_t (or adds/changes/removes LOCATION_BLOCK in it), when it is not queues it for next apply_location_cache. Now, when streaming in -g input, we can see extra locations that don't appear with -g0, and if we are unlucky enough, those can be sorted last during apply_location_cache and affect what locations are used from the single entry cache next. In particular, second apply_location_cache with non-empty loc_cache in the testcase has 14 locations with -g0 and 16 with -g and those 2 extra ones sort both last (they are the same). The last one from -g0 then appears to be input_location_and_block sourced again, for -g0 triggers the single entry cache, while for -g it doesn't and so apply_location_cache will create for it another location_t with the same content. The following patch fixes it by comparing everything we care about the location instead (well, better in addition) to a simple location_t == location_t check. I think we don't care about the sysp flag for debug info... 2022-01-28 Jakub Jelinek PR lto/104237 * cfgrtl.c (loc_equal): New function. (unique_locus_on_edge_between_p): Use it. (cherry picked from commit 430dca620fa3d03e53f6771a2b61d3f0ebb73756)
[Bug lto/104237] [11 Regression] Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute since r11-3126-ga8f9b4c54cc35062
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237 --- Comment #10 from Jakub Jelinek --- Because -fcompare-debug tells the driver to compile the TU twice, once without and once with -gtoggle, and compare the result. So, if there is a difference in the generated IL e.g. for -flto -ffat-lto-objects, it will detect it. Just watch gcc -flto -O1 pr104237.c -o pr104237 -g -fcompare-debug -v 2>&1 | grep 'cc1\|lto1' to see that, cc1 is invoked twice, once without -gtoggle, once with it, but lto1 is invoked just twice, once for wpa and once for ltrans. Even if you convince the linker plugin to pass -fcompare-debug even to the driver that invokes lto1, that would again compare lto1 with and without -g but only on a single input (depending on whether the original command line has -g with or without debug stmts in it). To reproduce this bug, one needs to do a "manual -fcompare-debug", which is gcc -flto -O1 pr104237.c -o pr104237 -g // + force lto1 to pass -fdump-final-insns=1 gcc -flto -O1 pr104237.c -o pr104237 // + force lto1 to pass -fdump-final-insns=2 diff -up 1 2 Now, in theory the driver could arrange that, but it would only handle the trivial case when the compilation and linking are from the same command. Typically with LTO, compilation is done separately and linking is done separately, and I don't see how the driver could arrange for that to work, we need in that case two sets of *.o files with the IL, one with -g0 and one with -g, link twice and compare the result at the end.
[Bug lto/104237] [11 Regression] Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute since r11-3126-ga8f9b4c54cc35062
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237 --- Comment #9 from Chengnian Sun --- Hi, Could you explain why the flag `-fcompare-debug` does not detect this bug? Is it because the bug is triggered with -flto and -fcompare-debug does not work with -flto? Thanks.
[Bug lto/104237] [11 Regression] Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute since r11-3126-ga8f9b4c54cc35062
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237 Jakub Jelinek changed: What|Removed |Added Summary|[11/12 Regression] Emitted |[11 Regression] Emitted |binary code changes when -g |binary code changes when -g |is enabled at -O1 -flto and |is enabled at -O1 -flto and |optimize attribute since|optimize attribute since |r11-3126-ga8f9b4c54cc35062 |r11-3126-ga8f9b4c54cc35062 --- Comment #8 from Jakub Jelinek --- Fixed on the trunk so far.
