[Bug gold/22820] ICF mismerges two very similar functions

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=22820

--- Comment #2 from cvs-commit at gcc dot gnu.org  ---
The master branch has been updated by Cary Coutant :

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=651d16203867f8013a0f78a2f2e24df8c02d1377

commit 651d16203867f8013a0f78a2f2e24df8c02d1377
Author: Cary Coutant 
Date:   Tue Apr 24 21:57:37 2018 -0700

Fix bug with relocation addends and merge sections with --icf.

During --icf processing, gold was incorrectly processing the relocation
addend for references to items in a merge section. PC-relative references
and other forms of reference with a biased base address require a
non-section local symbol, where the addend is purely the bias.

gold/
PR gold/20642
PR gold/22820
* gc.h (gc_process_relocs): Flag STT_SECTION symbols in symvec.
* icf.cc (get_section_contents): For merge sections, ignore the
addend for relocations against non-section symbols.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gold/22820] ICF mismerges two very similar functions

[ccoutant at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22820

Cary Coutant  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Cary Coutant  ---
The two functions do have different relocations, so the linker should be
able to tell them apart. Unfortunately, gold is factoring in the
relocation addends when it shouldn't. References to items in a merge
section use a local symbol to point to the item, and use the addend
only to correct for a pc-relative bias (or for some other form of
non-zero base). Therefore, when the relocation points to a non-section
symbol, we should ignore the addend when trying to figure out which
item in the merge section we're pointing to (and then add the addend
back in only after identifying that target).

GCC 7 with -O produced a slightly different form of bias. In earlier
versions, we would see a small negative bias (e.g., .LC1 - 4), and
the code was ignoring those small negative biases (correctly, but for
the wrong reason). As a result, we were identifying the correct targets
and refusing to fold the two functions. With the new code, we're seeing
positive biases (e.g., .LC1 + 6 and .LC2 + 6). If we don't ignore the
addends, we look at the two strings, but we are ignoring the first 6
characters of each string. In this test case, the differences between
the two strings are only in the first character, so we mistakenly
conclude that the functions really are identical!

Even though the results are very different, this is the same bug as
PR 20642.

*** This bug has been marked as a duplicate of bug 20642 ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gold/22820] ICF mismerges two very similar functions

[ppluzhnikov at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22820

Paul Pluzhnikov  changed:

   What|Removed |Added

 CC||ppluzhnikov at google dot com,
   ||tmsriram at google dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils