[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 --- Comment #41 from CVS Commits --- The releases/gcc-9 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:faed344ee5f17b9a19961b3b1f8ea0ed10db6f2d commit r9-9208-gfaed344ee5f17b9a19961b3b1f8ea0ed10db6f2d Author: Eric Botcazou Date: Thu Jan 28 11:31:35 2021 +0100 Fix LTO bootstrap on Windows The latest fix introduced a comparison of executables and this cannot directly work on Windows because they are timestamped. Moreover nobody sets $(exeext) at top level, at least on MinGW, so you get weird behavior because some tools add the implicit .exe suffix and others do not. contrib/ PR lto/85574 * compare-lto: Deal with PE-COFF executables specifically.
[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 --- Comment #40 from CVS Commits --- The releases/gcc-10 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:4be929be0317b2baf1c67b430ad0a2fbaed05152 commit r10-9307-g4be929be0317b2baf1c67b430ad0a2fbaed05152 Author: Eric Botcazou Date: Thu Jan 28 11:31:35 2021 +0100 Fix LTO bootstrap on Windows The latest fix introduced a comparison of executables and this cannot directly work on Windows because they are timestamped. Moreover nobody sets $(exeext) at top level, at least on MinGW, so you get weird behavior because some tools add the implicit .exe suffix and others do not. contrib/ PR lto/85574 * compare-lto: Deal with PE-COFF executables specifically.
[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 --- Comment #39 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:f7a6d314e7f7eeb6240a4f62511c189c90ef300c commit r11-6951-gf7a6d314e7f7eeb6240a4f62511c189c90ef300c Author: Eric Botcazou Date: Thu Jan 28 11:31:35 2021 +0100 Fix LTO bootstrap on Windows The latest fix introduced a comparison of executables and this cannot directly work on Windows because they are timestamped. Moreover nobody sets $(exeext) at top level, at least on MinGW, so you get weird behavior because some tools add the implicit .exe suffix and others do not. contrib/ PR lto/85574 * compare-lto: Deal with PE-COFF executables specifically.
[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 --- Comment #38 from Eric Botcazou --- > Feel free to improve things - I do not have any Windows system to > test on or an idea what you think needs to be improved. I would > guess similar things apply to compare-debug which it was derived from. That's even more broken than initially thought: nobody sets $(exeext) at top level so gcc/lto1 is passed and then the behavior is random since some tools apppend the missing .exe implicitly and some don't.
[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 --- Comment #37 from rguenther at suse dot de --- On Wed, 27 Jan 2021, ebotcazou at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 > > --- Comment #36 from Eric Botcazou --- > > Because I didn't try to invent a clever way to detect which ones will > > actually exist (but I know lto1 will). Sure some extra-compare-if-exists > > could be invented. If there's no way to compare binaries on windows > > then there's maybe a way to conditionalize the extra-compare setting > > in the makefile fragment. > > There is one, see above. And it looks like contrib/compare-lto should be > rewritten from scratch, it takes a lot of time on Windows for nothing IIUC. Feel free to improve things - I do not have any Windows system to test on or an idea what you think needs to be improved. I would guess similar things apply to compare-debug which it was derived from.
[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 --- Comment #36 from Eric Botcazou --- > Because I didn't try to invent a clever way to detect which ones will > actually exist (but I know lto1 will). Sure some extra-compare-if-exists > could be invented. If there's no way to compare binaries on windows > then there's maybe a way to conditionalize the extra-compare setting > in the makefile fragment. There is one, see above. And it looks like contrib/compare-lto should be rewritten from scratch, it takes a lot of time on Windows for nothing IIUC.
[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 --- Comment #35 from Richard Biener --- (In reply to Eric Botcazou from comment #33) > The bootstrap-lto.mk patch breaks LTO bootstrap on Windows: you cannot > compare executables on this system since they are timestamped. I really > don't see the point in this patch, why comparing lto1 and not other > compilers? Because I didn't try to invent a clever way to detect which ones will actually exist (but I know lto1 will). Sure some extra-compare-if-exists could be invented. If there's no way to compare binaries on windows then there's maybe a way to conditionalize the extra-compare setting in the makefile fragment.
[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 --- Comment #34 from Eric Botcazou --- "cmp -i 256" seems to be a way out though.
[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #33 from Eric Botcazou --- The bootstrap-lto.mk patch breaks LTO bootstrap on Windows: you cannot compare executables on this system since they are timestamped. I really don't see the point in this patch, why comparing lto1 and not other compilers?
[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 --- Comment #32 from Richard Biener --- Author: rguenth Date: Thu May 2 13:58:47 2019 New Revision: 270798 URL: https://gcc.gnu.org/viewcvs?rev=270798&root=gcc&view=rev Log: 2019-05-02 Richard Biener PR bootstrap/85574 * Makefile.tpl (compare target): Also compare extra-compare files. * Makefile.in: Regenerate. config/ * bootstrap-lto.mk (extra-compare): Set to gcc/lto1$(exeext). Modified: trunk/ChangeLog trunk/Makefile.in trunk/Makefile.tpl trunk/config/ChangeLog trunk/config/bootstrap-lto.mk
[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 --- Comment #31 from Richard Biener --- (In reply to Jan Hubicka from comment #30) > We may still want to backport to gcc 7 branch. The ICF bug at least > exists there as well. Sure.
[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 --- Comment #30 from Jan Hubicka --- We may still want to backport to gcc 7 branch. The ICF bug at least exists there as well.
[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #29 from Richard Biener --- Fixed.
[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 --- Comment #28 from Jan Hubicka --- Author: hubicka Date: Thu Jan 10 16:53:39 2019 New Revision: 267817 URL: https://gcc.gnu.org/viewcvs?rev=267817&root=gcc&view=rev Log: Backported from mainline 2019-01-02 Richard Biener PR ipa/85574 * ipa-icf.h (sem_item_optimizer::sort_congruence_split): Declare. * ipa-icf.c (sem_item_optimizer::sort_congruence_split): New function. (sem_item_optimizer::do_congruence_step_f): Sort the congruence set after UIDs before splitting them. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/ipa-icf.c branches/gcc-8-branch/gcc/ipa-icf.h
[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 --- Comment #27 from Jan Hubicka --- Author: hubicka Date: Thu Jan 10 11:54:26 2019 New Revision: 267805 URL: https://gcc.gnu.org/viewcvs?rev=267805&root=gcc&view=rev Log: PR tree-optimization/85574 Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/tree-ssa-uncprop.c
[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 --- Comment #26 from Richard Biener --- Author: rguenth Date: Thu Jan 3 12:23:27 2019 New Revision: 267552 URL: https://gcc.gnu.org/viewcvs?rev=267552&root=gcc&view=rev Log: 2019-01-03 Jan Hubicka PR tree-optimization/85574 * tree-ssa-uncprop.c (struct equiv_hash_elt): Remove unused structure. (struct ssa_equip_hash_traits): Declare. (val_ssa_equiv): Use custom hash traits using operand_equal_p. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-uncprop.c
[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 --- Comment #25 from Jan Hubicka --- I have tracked down the firefox issue to be -fno-lifetime-dse=1 being used in with -fprofile-use but not with -fprofile-generate. I am down to 36 mismatches now and those seems real sourcecode changes (will analyze them after another rebuild)
[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 --- Comment #24 from Jan Hubicka --- > Patch needs ">>>" to be repaced by "> > >" to bootstrap, but then I get 756 > mismatches building firefox, while previously it was 1300 and before the > rebuild_type_inheritance_graph 6273, so we are improving. I will look into > the > remaining cases. Actually I was wrong - grepped wrong file. Still 1300 warnings. I am looking into that - perhaps these are same problems. Still I think the patch for uncprop makes sense. Honza
[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 --- Comment #23 from Jan Hubicka --- Patch needs ">>>" to be repaced by "> > >" to bootstrap, but then I get 756 mismatches building firefox, while previously it was 1300 and before the rebuild_type_inheritance_graph 6273, so we are improving. I will look into the remaining cases. Can't the type sharing difference come from GTY((cache)) use in tree.h?
[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 --- Comment #22 from Jan Hubicka --- Created attachment 45318 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45318&action=edit patch for operand_equal_p in tree-ssa-uncprop
[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 --- Comment #21 from Jan Hubicka --- Looks like last minute change in this patch https://gcc.gnu.org/ml/gcc-cvs/2014-06/msg00838.html https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01600.html
[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574
--- Comment #20 from rguenther at suse dot de ---
On January 2, 2019 5:25:09 PM GMT+01:00, "hubicka at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574
>
>--- Comment #19 from Jan Hubicka ---
>gcc 5 has:
>inline bool
>
>val_ssa_equiv_hash_traits::equal_keys (tree value1, tree value2)
>
>{
>
>return operand_equal_p (value1, value2, 0);
>
>}
>
>
>/* Free an instance of equiv_hash_elt. */
>
>
>template
>
>inline void
>
>val_ssa_equiv_hash_traits::remove (T &elt)
>
>{
>
>elt.m_value.release ();
>
>}
>
>
>while in mainline we seem to compare addresses... Looks like wrong
>update to
>hash_map.
But still it doesn't explain differences in tree sharing between stage2 and
three.
But yes, I'll go track things down a bit more.
[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574
--- Comment #19 from Jan Hubicka ---
gcc 5 has:
inline bool
val_ssa_equiv_hash_traits::equal_keys (tree value1, tree value2)
{
return operand_equal_p (value1, value2, 0);
}
/* Free an instance of equiv_hash_elt. */
template
inline void
val_ssa_equiv_hash_traits::remove (T &elt)
{
elt.m_value.release ();
}
while in mainline we seem to compare addresses... Looks like wrong update to
hash_map.
[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 --- Comment #18 from Richard Biener --- OK, so it looks like uncprop causes a lot of differences (minor dump differences appear from profile-estimate and printf-return-value2 as well). --- prev-gcc/cc1.ltrans99.196t.uncprop1 2019-01-02 16:06:25.701672034 +0100 +++ gcc/cc1.ltrans99.196t.uncprop1 2019-01-02 16:19:03.713847999 +0100 @@ -20478,7 +20478,7 @@ [local count: 28992085]: # reject_602 = PHI # this_alternative_850 = PHI - # _44 = PHI <_(229), _(656), _(657), _(659), 1(655), _(658), 1(873)> + # _44 = PHI <_(229), _(656), _(657), _(659), _(655), _(658), 1(873)> # DEBUG reject => reject_602 # DEBUG BEGIN_STMT # DEBUG this_alternative_offmemok => offmemok_671
[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 --- Comment #17 from Richard Biener --- Author: rguenth Date: Wed Jan 2 08:49:07 2019 New Revision: 267506 URL: https://gcc.gnu.org/viewcvs?rev=267506&root=gcc&view=rev Log: 2019-01-02 Richard Biener PR ipa/85574 * ipa-icf.h (sem_item_optimizer::sort_congruence_split): Declare. * ipa-icf.c (sem_item_optimizer::sort_congruence_split): New function. (sem_item_optimizer::do_congruence_step_f): Sort the congruence set after UIDs before splitting them. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-icf.c trunk/gcc/ipa-icf.h
[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 --- Comment #16 from Richard Biener --- (In reply to Richard Biener from comment #15) > Created attachment 45278 [details] > patch for the ICF issue > > Conveniently the congruence_classes have a UID. So the attached sorts after > that before traversing / splitting. > > So testing the attached. Of course the patch didn't fix the miscompare. It fixes the IPA ICF dump difference though (the :370 vs. :371 "issue") remains. The .fixup_cfg LTRANS dump debug stmt differences remain as well. The same ltrans unit at .optimized has additional code-gen differences: [local count: 56209456]: # _462 = PHI <_354(182), _122(177), _354(184)> - # would_overrun_p_183 = PHI + # would_overrun_p_183 = PHI # _218 = PHI <_375(182), 1(177), _375(184)>
[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 --- Comment #15 from Richard Biener --- Created attachment 45278 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45278&action=edit patch for the ICF issue Conveniently the congruence_classes have a UID. So the attached sorts after that before traversing / splitting. So testing the attached.
[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 --- Comment #14 from Jan Hubicka --- > Yeah. Note that the debug stmt differences _might_ be explained by > ICF in case ICF ignores debug stmts when merging. But since the > ICF dumps are ordered differently it's hard to see actual decision > differences... Yep, ICF ignores debug statements and choice of the leading function from the group depends on memory layout it will diverge on that. Which of course is a bug... Honza
[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|9.0 |8.3 Summary|[9 Regression] LTO |[8/9 Regression] LTO |bootstapped binaries differ |bootstapped binaries differ --- Comment #13 from Richard Biener --- -fno-reorder-blocks-and-partition does not help. @@ -115230,59624 +115230,59628 @@ 5e1fa6: 44 88 74 24 18 mov%r14b,0x18(%rsp) 5e1fab: e9 77 f7 ff ff jmpq 5e1727 <_Z14composite_typeP9tree_nodeS0_.part.56+0x4c7> 5e1fb0: 80 7c 24 27 00 cmpb $0x0,0x27(%rsp) - 5e1fb5: 75 17 jne5e1fce <_Z14composite_typeP9tree_nodeS0_.part.56+0xd6e> - 5e1fb7: 31 c0 xor%eax,%eax - 5e1fb9: 0f b6 4c 24 27 movzbl 0x27(%rsp),%ecx - 5e1fbe: 45 31 ffxor%r15d,%r15d - 5e1fc1: 88 44 24 27 mov%al,0x27(%rsp) - 5e1fc5: 88 4c 24 10 mov%cl,0x10(%rsp) - 5e1fc9: e9 59 f7 ff ff jmpq 5e1727 <_Z14composite_typeP9tree_nodeS0_.part.56+0x4c7> - 5e1fce: 48 89 dfmov%rbx,%rdi - 5e1fd1: 4c 89 5c 24 10 mov%r11,0x10(%rsp) - 5e1fd6: e8 f5 8c fa ff callq 58acd0 <_Z12c_vla_type_pPK9tree_node> - 5e1fdb: 4c 8b 5c 24 10 mov0x10(%rsp),%r11 - 5e1fe0: 88 44 24 27 mov%al,0x27(%rsp) - 5e1fe4: b8 01 00 00 00 mov$0x1,%eax - 5e1fe9: eb ce jmp5e1fb9 <_Z14composite_typeP9tree_nodeS0_.part.56+0xd59> - 5e1feb: 45 31 c9xor%r9d,%r9d ... - 5e26b6: 66 2e 0f 1f 84 00 00nopw %cs:0x0(%rax,%rax,1) - 5e26bd: 00 00 00 - -005e26c0 <_ZL19common_pointer_typeP9tree_nodeS0_>: - 5e26c0: 48 39 f7cmp%rsi,%rdi - 5e26c3: 0f 84 07 02 00 00 je 5e28d0 <_ZL19common_pointer_typeP9tree_nodeS0_+0x210> - 5e26c9: 48 8b 05 10 18 91 01mov0x1911810(%rip),%rax# 1ef3ee0 - 5e26d0: 48 39 f8cmp%rdi,%rax ... - -005e2a30 <_Z14composite_typeP9tree_nodeS0_>: - 5e2a30: 48 39 f7cmp%rsi,%rdi - 5e2a33: 74 1b je 5e2a50 <_Z14composite_typeP9tree_nodeS0_+0x20> - 5e2a35: 48 8b 05 a4 14 91 01mov0x19114a4(%rip),%rax# 1ef3ee0 - 5e2a3c: 48 39 f8cmp%rdi,%rax - 5e2a3f: 74 1f je 5e2a60 <_Z14composite_typeP9tree_nodeS0_+0x30> - 5e2a41: 48 39 f0cmp%rsi,%rax - 5e2a44: 74 0a je 5e2a50 <_Z14composite_typeP9tree_nodeS0_+0x20> - 5e2a46: e9 15 e8 ff ff jmpq 5e1260 <_Z14composite_typeP9tree_nodeS0_.part.56> - 5e2a4b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) - 5e2a50: 48 89 f8mov%rdi,%rax + 5e1fb5: 75 0d jne5e1fc4 <_Z14composite_typeP9tree_nodeS0_.part.56+0xd64> + 5e1fb7: c6 44 24 10 00 movb $0x0,0x10(%rsp) + 5e1fbc: 45 31 ffxor%r15d,%r15d + 5e1fbf: e9 63 f7 ff ff jmpq 5e1727 <_Z14composite_typeP9tree_nodeS0_.part.56+0x4c7> + 5e1fc4: 48 89 dfmov%rbx,%rdi + 5e1fc7: 4c 89 5c 24 28 mov%r11,0x28(%rsp) + 5e1fcc: e8 ff 8c fa ff callq 58acd0 <_Z12c_vla_type_pPK9tree_node> + 5e1fd1: 4c 8b 5c 24 28 mov0x28(%rsp),%r11 + 5e1fd6: 88 44 24 10 mov%al,0x10(%rsp) Btw, I see the same issue on the GCC 8 branch head. Have yet to find where it actually doesn't miscompare so maybe it isn't a regression after all.
