https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #70 from Eric Gallager ---
With some distributions wanting to make LTO the default, I'd think this issue
might become a bit more important...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #69 from Eric Gallager ---
*** Bug 61440 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #68 from Richard Biener ---
(In reply to Sven C. Dack from comment #67)
> (In reply to Richard Biener from comment #66)
> > The issue re-appears with GCC 6, the workaround doing
> > --enable-stage1-checking=release still works.
> >
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #67 from Sven C. Dack ---
(In reply to Richard Biener from comment #66)
> The issue re-appears with GCC 6, the workaround doing
> --enable-stage1-checking=release still works.
>
> Note that the comparison we do with LTO bootstrap is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #66 from Richard Biener ---
The issue re-appears with GCC 6, the workaround doing
--enable-stage1-checking=release still works.
Note that the comparison we do with LTO bootstrap is quite pointless as we
only compile the internal IL a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
Version|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #64 from Jakub Jelinek ---
Author: jakub
Date: Fri Apr 17 17:10:27 2015
New Revision: 222189
URL: https://gcc.gnu.org/viewcvs?rev=222189&root=gcc&view=rev
Log:
PR bootstrap/62077
* configure.ac (--enable-stage1-checking): Def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #63 from Jakub Jelinek ---
Author: jakub
Date: Fri Apr 17 17:09:20 2015
New Revision: 222187
URL: https://gcc.gnu.org/viewcvs?rev=222187&root=gcc&view=rev
Log:
PR bootstrap/62077
* configure.ac (--enable-stage1-checking): Def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #62 from Richard Biener ---
Works for me. Of course we should hunt down IL differences that appear with
GC.
It's just a lurking bug that can hit the non-GC checking path as well.
But all this is exceptionally hard to track down :/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #61
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #60 from Richard Biener ---
Workaround confirmed for GCC 5 (--enable-stage1-checking=release).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #59 from rguenther at suse dot de ---
On Wed, 15 Apr 2015, vekumar at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
>
> vekumar at gcc dot gnu.org changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
vekumar at gcc dot gnu.org changed:
What|Removed |Added
CC||vekumar at gcc dot gnu.org
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
Richard Biener changed:
What|Removed |Added
Known to fail||4.8.4, 4.9.2, 5.1.0
--- Comment #57 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #56 from Sven C. Dack ---
> I don't see why we need to fix this for the 4.9 or 4.8 branch. It never
> worked there and another existing workaround is to configure with
> --enable-stage1-checking=release.
One reason is that it is not
rounds
Regards,
Venkat.
-Original Message-
From: rguenther at suse dot de [mailto:gcc-bugzi...@gcc.gnu.org]
Sent: Monday, August 18, 2014 7:11 PM
To: Kumar, Venkataramanan
Subject: [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6207
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #54 from rguenther at suse dot de ---
On Mon, 18 Aug 2014, venkataramanan.kumar at amd dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
>
> --- Comment #53 from Venkataramanan ---
> Hi Richard,
>
> >> Well, it
onday, August 18, 2014 6:41 PM
To: Kumar, Venkataramanan
Subject: [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #52 from rguenther at suse dot de --- On
Mon, 18 Aug 2014, venkataramanan.kumar at amd dot com wrote
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #52 from rguenther at suse dot de ---
On Mon, 18 Aug 2014, venkataramanan.kumar at amd dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
>
> --- Comment #51 from Venkataramanan ---
> (In reply to rguent...@suse.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #51 from Venkataramanan ---
(In reply to rguent...@suse.de from comment #35)
> On Thu, 14 Aug 2014, venkataramanan.kumar at amd dot com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
> >
> > --- Comment #34 from Ven
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #50 from Sven C. Dack ---
The additional configuration options --enable-linker-plugin-configure-flags=
and --enable-linker-plugin-flags=, which I have trusted in and taken from
https://gcc.gnu.org/install/configure.html do not seem to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #49 from Sven C. Dack ---
The problem seems to be a missing liblto_plugin.so in gcc's directory for
stage2. I used:
--with-boot-ldflags="-static -flto=1 -flto-partition=none -fuse-linker-plugin"
together with:
--enable-linker-plugi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #48 from Sven C. Dack ---
> ...
> > With the linker plugin enabled does it actually link libgcc_s.so and
> > libstdc++.so dynamically to it, while for the other three it did not:
>
> That looks odd. Btw, -fuse-linker-plugin should b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #47 from Sven C. Dack ---
> default:84920k
> profiled: 90176k
> lto:71204k
> lto-plugin: 60024k
The new file sizes of cc1's are:
default: 84920k
profiled: 90176k
lto: 71204k
profiled-lto: 98556k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #46 from Sven C. Dack ---
> ...
> > > > avg stdev %
> > > > default:282.86s0.56s, 0.20%100.00% (base)
> > > > profiled: 255.76s0.72s, 0.28%+10.60%
> > > > lto:282.80s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #45 from Jason Merrill ---
Author: jason
Date: Fri Aug 15 17:27:58 2014
New Revision: 214030
URL: https://gcc.gnu.org/viewcvs?rev=214030&root=gcc&view=rev
Log:
PR bootstrap/62077
gcc/
* tree.c (type_hash_canon): Uncomment ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #44 from Markus Trippelsdorf ---
(In reply to Sven C. Dack from comment #43)
> (In reply to Markus Trippelsdorf from comment #42)
> > (In reply to Sven C. Dack from comment #40)
> > > The results are the averages (and deviations) of 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #43 from Sven C. Dack ---
(In reply to Markus Trippelsdorf from comment #42)
> (In reply to Sven C. Dack from comment #40)
> > The results are the averages (and deviations) of 5 runs with each compiler:
> >
> > avg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #42 from Markus Trippelsdorf ---
(In reply to Sven C. Dack from comment #40)
> The results are the averages (and deviations) of 5 runs with each compiler:
>
> avg stdev %
> default:282.86s0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #41 from rguenther at suse dot de ---
On Fri, 15 Aug 2014, sven.c.dack at virginmedia dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
>
> --- Comment #40 from Sven C. Dack ---
> I ran benchmarks and got some unu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #40 from Sven C. Dack ---
I ran benchmarks and got some unusual results. Or perhaps it is a regression?
I have created 4 versions of gcc and used these to timed the time it takes to
compile a linux kernel. The configuration of the 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #39 from Sven C. Dack ---
(In reply to Sven C. Dack from comment #38)
> The testsuite run looks good:
>
> # of expected passes 105750
> # of unexpected failures 3
> # of expected failures252
> # of expec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #38 from Sven C. Dack ---
The testsuite run looks good:
# of expected passes105750
# of unexpected failures3
# of expected failures252
# of expected passes87886
# of unexpected failures2
# of unexpecte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #37 from Sven C. Dack ---
> ...
> trying
>
> Index: config/bootstrap-lto.mk
> ===
> --- config/bootstrap-lto.mk (revision 213899)
> +++ config/bootstrap-lto.mk (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #36 from Andrew Pinski ---
(In reply to rguent...@suse.de from comment #35)
> On Thu, 14 Aug 2014, venkataramanan.kumar at amd dot com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
> >
> > --- Comment #34 from Venk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #35 from rguenther at suse dot de ---
On Thu, 14 Aug 2014, venkataramanan.kumar at amd dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
>
> --- Comment #34 from Venkataramanan ---
> Richard, What I understand is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #34 from Venkataramanan ---
Richard, What I understand is that instead of using tune flags for garbage
collection, need to try and fix the object code differences?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #33 from Richard Biener ---
Another difference - graphite-interchange.o - is due to streaming the indexed
decl for fprintf differently. stage2 streams
[1968] = tree_list <0x76703ac8>
[1969] = identifier_node <0x766ddf20>
[19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #32 from Richard Biener ---
Yeah, to summarize:
- Using --param ggc-min-expand=100 --param ggc-min-heapsize=131072 fixes
LTO bootstrap (I tested x86_64 on the 4.9 branch)
- Using the patch from comment #26 doesn't fix LTO boots
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #31 from Venkataramanan ---
(In reply to Venkataramanan from comment #30)
> (In reply to Venkataramanan from comment #29)
> > Hi Richard,
> >
> > I tried the patch you posted last on GCC patches, on top of GCC 4.9 on
> > Aarch64.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #30 from Venkataramanan ---
(In reply to Venkataramanan from comment #29)
> Hi Richard,
>
> I tried the patch you posted last on GCC patches, on top of GCC 4.9 on
> Aarch64.
> https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01324.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #29 from Venkataramanan ---
Hi Richard,
I tried the patch you posted last on GCC patches, on top of GCC 4.9 on Aarch64.
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01324.html
I am still getting same number of compare errors.
Now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #28 from Venkataramanan ---
Richard,
I am still not able to understand why this problem is not seen in trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #27 from Sven C. Dack ---
(In reply to Richard Biener from comment #24)
> Or "real" fix for the type_hash_canon issue (untested)
>
> Index: gcc/tree.c
> ===
> --- gcc/tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
Richard Biener changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #24 from Richard Biener ---
Or "real" fix for the type_hash_canon issue (untested)
Index: gcc/tree.c
===
--- gcc/tree.c (revision 213814)
+++ gcc/tree.c (working copy)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #23 from Richard Biener ---
(In reply to Richard Biener from comment #22)
> So if I instrument build_string_literal with
>
> Index: builtins.c
> ===
> --- builtins.c (r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #22 from Richard Biener ---
So if I instrument build_string_literal with
Index: builtins.c
===
--- builtins.c (revision 213814)
+++ builtins.c (working copy)
@@ -59,6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #21 from Venkataramanan ---
I randomly tried some revisions and last one that passed was r209650 on
2014-04-22. I am still continuing to go down and see some more revision.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #20 from Richard Biener ---
(In reply to Richard Biener from comment #19)
> Note that the differences can be reproduced even with non-LTO cc1/cc1plus.
> Thus,
> do a regular bootstrap --without-build-config then re-build stage2
> bui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #19 from Richard Biener ---
Note that the differences can be reproduced even with non-LTO cc1/cc1plus.
Thus,
do a regular bootstrap --without-build-config then re-build stage2
build/genconfig.o with -flto (using
the stage1 compiler)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
Sven C. Dack changed:
What|Removed |Added
Attachment #33299|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
Sven C. Dack changed:
What|Removed |Added
Summary|--with-build-config=bootstr |--with-build-config=bootstr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #16 from Richard Biener ---
Ok, so what happens is that for build/genconfig.o we in one case write
a STRING_CST with a const char[7] with itself as main-variant and in
the other case with char[7] as main-variant. The STRING_CST is
wr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #15 from Sven C. Dack ---
(In reply to Venkataramanan from comment #14)
> ...
> I tried addding to stage2/3 the flags "-flto=1 -flto-partition=none" instead
> of jobserver in bootstrap-lto.mk and spawned bootstrap LTO build in one
> a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #14 from Venkataramanan ---
(In reply to Sven C. Dack from comment #6)
> It seems the problem is caused by the use of the jobserver. Changing
> bootstrap-lto.mk from:
>
> ...
> STAGE2_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #13 from Richard Biener ---
(In reply to Richard Biener from comment #12)
> Ok, so there is one thing that changed (but only very recently) on trunk
> which
> is improved hashing of SCCs and thus more consistent ordering.
>
> Especia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #12 from Richard Biener ---
Ok, so there is one thing that changed (but only very recently) on trunk which
is improved hashing of SCCs and thus more consistent ordering.
Especially I'm talking about the fact that at compile-time (!)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #11 from Venkataramanan ---
I am also trying to fix LTO bootstrap compare failure in Aarch64.
Bootstrap compare failure is not occurring in GCC FSF trunk (tested on aarch64
as well as x86_64 machine). Now I am doing one more round of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #10 from rguenther at suse dot de ---
On Tue, 12 Aug 2014, trippels at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
>
> Markus Trippelsdorf changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
Markus Trippelsdorf changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #8 from Andrew Pinski ---
(In reply to Sven C. Dack from comment #7)
> Created attachment 33299 [details]
> Removes the use of the jobserver from bootstrap-lto.mk
>
> The patch changes bootstrap-lto.mk to use a single, unpartitioned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
Sven C. Dack changed:
What|Removed |Added
Attachment #33285|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #6 from Sven C. Dack ---
It seems the problem is caused by the use of the jobserver. Changing
bootstrap-lto.mk from:
...
STAGE2_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects
STAGE3_CFLAGS += -flto=jobserver -frandom-see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #5 from Venkataramanan ---
(In reply to Richard Biener from comment #4)
> Also fails with the 4.9.0 release on x86_64.
Also fails with the GCC 4.9 on Aarch64 target.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
--- Comment #4 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
Richard Biener changed:
What|Removed |Added
Keywords||build, lto
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
Sven C. Dack changed:
What|Removed |Added
CC||sven.c.dack at virginmedia dot
com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #1 from Sven C. Dack ---
I have worked around the problem by adding a line to 'bootstrap-lto.mk' and to
let it use a script for comparing object files based only on their disassembled
code.
I assume when the disassembled output of th
71 matches
Mail list logo