[Bug lto/104237] New: Emitted binary code changes when -g is enabled at -O1 -flto

[Bug lto/104237] New: Emitted binary code changes when -g is enabled at -O1 -flto

[tlwang at uwaterloo dot ca]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237

            Bug ID: 104237
           Summary: Emitted binary code changes when -g is enabled at -O1
                    -flto
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tlwang at uwaterloo dot ca
                CC: marxin at gcc dot gnu.org
  Target Milestone: ---

This occurs when compiling attributes_transformed_program0_preprocessed.c, as
shown below.

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.scGtRTj8uf-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.1 20220125 (experimental) [master -gf4ee27d32] (GCC)
$ cat attributes_transformed_program0_preprocessed.c
# 6 ""
short a;
__attribute__((optimize(0))) int b();
__attribute__((always_inline)) signed char c();
int b() {
  char e = c();
  return a;
}
signed char c(f) {
  d();
# 7 "attributes_transformed_program0.c"
  int g;
# 6
  return f;
}
void d() {}
int main() {}
$ gcc-trunk -w -O1 -flto attributes_transformed_program0_preprocessed.c -o
a.out
$ objdump --disassemble --section=.text a.out > no_debug.txt
$ gcc-trunk -w -O1 -flto -g attributes_transformed_program0_preprocessed.c -o
a.out
$ objdump --disassemble --section=.text a.out > debug.txt
$ diff debug.txt no_debug.txt
18c18
<   401041:     48 c7 c7 1e 11 40 00    mov    $0x40111e,%rdi
---
>   401041:	48 c7 c7 1d 11 40 00 	mov    $0x40111d,%rdi
88,91c88,91
<   40110d:     90                      nop
<   40110e:     88 45 ff                mov    %al,-0x1(%rbp)
<   401111:     0f b7 05 ec 0e 00 00    movzwl 0xeec(%rip),%eax        # 402004
<a>
<   401118:     98                      cwtl
---
>   40110d:	88 45 ff             	mov    %al,-0x1(%rbp)
>   401110:	0f b7 05 ed 0e 00 00 	movzwl 0xeed(%rip),%eax        # 402004 <a>
>   401117:	98                   	cwtl
>   401118:	90                   	nop
93,95c93,94
<   40111a:     90                      nop
<   40111b:     5d                      pop    %rbp
<   40111c:     c3                      retq
---
>   40111a:	5d                   	pop    %rbp
>   40111b:	c3                   	retq
97,98c96,97
< 000000000040111d <d>:
<   40111d:     c3                      retq
---
> 000000000040111c <d>:
>   40111c:	c3                   	retq
100,105c99,104
< 000000000040111e <main>:
<   40111e:     b8 00 00 00 00          mov    $0x0,%eax
<   401123:     c3                      retq
<   401124:     66 2e 0f 1f 84 00 00    nopw   %cs:0x0(%rax,%rax,1)
<   40112b:     00 00 00
<   40112e:     66 90                   xchg   %ax,%ax
---
> 000000000040111d <main>:
>   40111d:	b8 00 00 00 00       	mov    $0x0,%eax
>   401122:	c3                   	retq
>   401123:	66 2e 0f 1f 84 00 00 	nopw   %cs:0x0(%rax,%rax,1)
>   40112a:	00 00 00
>   40112d:	0f 1f 00             	nopl   (%rax)

[Bug lto/104237] Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Emitted binary code changes |Emitted binary code changes
                   |when -g is enabled at -O1   |when -g is enabled at -O1
                   |-flto                       |-flto and optimize
                   |                            |attribute

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I suspect this is an optimize attribute issue rather than a -g based one.

[Bug lto/104237] [11/12 Regression] Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute since r11-3126-ga8f9b4c54cc35062

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Emitted binary code changes |[11/12 Regression] Emitted
                   |when -g is enabled at -O1   |binary code changes when -g
                   |-flto and optimize          |is enabled at -O1 -flto and
                   |attribute                   |optimize attribute since
                   |                            |r11-3126-ga8f9b4c54cc35062
   Last reconfirmed|                            |2022-01-26
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with r11-3126-ga8f9b4c54cc35062.

[Bug lto/104237] [11/12 Regression] Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute since r11-3126-ga8f9b4c54cc35062

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dmalcolm at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
*.optimized looks the same, code generation diverges in *.expand.
The difference is that unique_locus_on_edge_between_p returns false vs. true
in between bb 2 and bb 4.
goto_locus is 0x80000002 in both cases, that expand_location to:
"pr104237.c":6:10 in both cases.
But the:
(insn 10005 10004 10007 2 (set (reg:QI 84 [ D.4728 ])
        (subreg:QI (reg:SI 86) 0)) "pr104237.c":6:10 -1
     (nil))
insn at the end of bb 2 has INSN_LOCATION 0x80000002 in the -g0 case and
INSN_LOCATION 0x80000004 in the -g case.
This means
799       if (insn != end && INSN_LOCATION (insn) == goto_locus)
800         return false;
in unique_locus_on_edge_between_p returns false in the -g0 case and true in -g
case and a nop is emitted only in the latter case.
The really strange thing is that (in the -g build):
(gdb) p expand_location (0x80000002)
$24 = {file = 0x3b6ba60 "pr104237.c", line = 6, column = 10, data =
0x7fffea06f180, sysp = false}
(gdb) p expand_location (0x80000004)
$25 = {file = 0x3b6ba60 "pr104237.c", line = 6, column = 10, data =
0x7fffea06f180, sysp = false}
i.e. everything is the same.
Even the adhoc table for 2 and 4:
(gdb) p line_table->location_adhoc_data_map.data[2]
$26 = {locus = 54368, src_range = {m_start = 54368, m_finish = 54368}, data =
0x7fffea06f180}
(gdb) p line_table->location_adhoc_data_map.data[4]
$27 = {locus = 58720, src_range = {m_start = 58720, m_finish = 58720}, data =
0x7fffea06f180}
contains different data, so even comparing LOCATION_LOCUS (INSN_LOCATION
(insn)) == LOCATION_LOCUS (goto_locus) wouldn't work here.

David, any idea on what the difference between 54368 and 58720 above could be
and why
(gdb) p expand_location (54368)
$28 = {file = 0x3b6ba60 "pr104237.c", line = 6, column = 10, data = 0x0, sysp =
false}
(gdb) p expand_location (58720)
$29 = {file = 0x3b6ba60 "pr104237.c", line = 6, column = 10, data = 0x0, sysp =
false}
?

Do we compare locations anywhere else (twice in cfgrtl.cc)?
Is the only reliable comparison expand_location and comparing the members of
that?

[Bug lto/104237] [11/12 Regression] Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute since r11-3126-ga8f9b4c54cc35062

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ah, as this is lto1, all the locations are created by
lto_location_cache::apply_location_cache.
With -g lto1 can stream more locations than with -g0, and apply_location_cache
is always called on some chunk of locations before we really need them, qsorts
the expanded locations and emits them into line_table. 
current_{file,line,col,sysp} are left after this call pointing to the last
entry added by apply_location_cache in following processing.  Locations that
match it will get LOCATION_LOCUS of current_loc, while otherwise they will be
pushed into processing by next apply_location_cache.
On this testcase (I'm actually working with:
# 6 ""
short a;
__attribute__((optimize(0))) int foo ();
__attribute__((always_inline)) signed char bar ();
int foo () {
  char e = bar ();
  return a;
}
signed char bar (f) {
  baz ();
# 7 "pr104237-2.c"
  int g;
# 6
  return f;
}
void baz () {}
int main () { return 0; }
) what happens is that on the second apply_location_cache call, with -g0 we
have 14 entries in loc_cache, while with -g 16 entries, the last two extra ones
after qsort come last.  So, when lto_location_cache::input_location_and_block
is called after this block, if it wants a location that was last with -g0 but
not with -g, it will reuse the last emitted entry in one case and not in the
other one and vice versa.
The extra 2 entries are in particular the g in int g;
So, I think either we need some much more expensive way to ensure we never have
duplicate locations from the LTO streaming in, or we need to use
expand_location content comparisons instead of (or in addition to) location_t
comparisons.

[Bug lto/104237] [11/12 Regression] Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute since r11-3126-ga8f9b4c54cc35062

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 52305
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52305&action=edit
gcc12-pr104237.patch

Untested fix.

[Bug lto/104237] [11/12 Regression] Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute since r11-3126-ga8f9b4c54cc35062

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.3

[Bug lto/104237] [11/12 Regression] Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute since r11-3126-ga8f9b4c54cc35062

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237

--- Comment #6 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
FWIW years ago I posted a patch to generalize libgccjit's location
consolidation code so that it could be used by LTO, but IIRC it was rejected. 
I spent a few minutes looking in the archives but wasn't able to find it.

[Bug lto/104237] [11/12 Regression] Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute since r11-3126-ga8f9b4c54cc35062

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:430dca620fa3d03e53f6771a2b61d3f0ebb73756

commit r12-6914-g430dca620fa3d03e53f6771a2b61d3f0ebb73756
Author: Jakub Jelinek <jakub@redhat.com>
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  <jakub@redhat.com>

            PR lto/104237
            * cfgrtl.cc (loc_equal): New function.
            (unique_locus_on_edge_between_p): Use it.

[Bug lto/104237] [11 Regression] Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute since r11-3126-ga8f9b4c54cc35062

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237

Jakub Jelinek <jakub at gcc dot gnu.org> 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 <jakub at gcc dot gnu.org> ---
Fixed on the trunk so far.

[Bug lto/104237] [11 Regression] Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute since r11-3126-ga8f9b4c54cc35062

[cnsun at uwaterloo dot ca]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237

--- Comment #9 from Chengnian Sun <cnsun at uwaterloo dot ca> ---
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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:88ff2eb5cc2c1af2ae751c02997d0b5667662782

commit r11-9594-g88ff2eb5cc2c1af2ae751c02997d0b5667662782
Author: Jakub Jelinek <jakub@redhat.com>
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  <jakub@redhat.com>

            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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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

[cnsun at uwaterloo dot ca]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237

--- Comment #13 from Chengnian Sun <cnsun at uwaterloo dot ca> ---
(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

[cnsun at uwaterloo dot ca]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237

--- Comment #14 from Chengnian Sun <cnsun at uwaterloo dot ca> ---
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

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237

--- Comment #15 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
-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

[cnsun at uwaterloo dot ca]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237

--- Comment #17 from Chengnian Sun <cnsun at uwaterloo dot ca> ---
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

[cnsun at uwaterloo dot ca]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237

--- Comment #18 from Chengnian Sun <cnsun at uwaterloo dot ca> ---
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

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237

--- Comment #19 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237

--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(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

[cnsun at uwaterloo dot ca]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237

--- Comment #21 from Chengnian Sun <cnsun at uwaterloo dot ca> ---
Thank you, Andrew and Jakub.