[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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 at LTO streaming time but not the final result
of optimization. For that we'd need to compare cc1, cc1plus, etc. itself.
So a fix would be to make the comparison configurable to a tri-stage
{ object-files, binaries, off } where a boostrap with comparison off
can also omit building stage3 but still get the benefit of building
GCC with itself and not the host compiler.
Comparing the binaries is generally slower of course.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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 quite pointless as we
> only compile the internal IL at LTO streaming time but not the final result
> of optimization. For that we'd need to compare cc1, cc1plus, etc. itself.
To call it pointless is as dismissive of the effort as saying you'd be willing
to accept any indeterministic behaviour, including magic, into computer science
as long as it produces great software. Let's not be this lazy.
I believe there is still much to be had from a comparison in between the stages
and of all that can be determined. This particular case here may not have
revealed a serious issue. However, it makes it only a fortunate case, but it's
not a reason to welcome indetermination and luck into GCC's development or to
dismiss a good concept. I'd rather fear that in doing so you'd lose further
support from the scientific community.
Anyhow, this is my opinion. I should in fact not be getting any e-mails on this
report - I have excluded myself from the list some time ago - and yet did I did
get the mail.
> So a fix would be to make the comparison configurable to a tri-stage
> { object-files, binaries, off } where a boostrap with comparison off
> can also omit building stage3 but still get the benefit of building
> GCC with itself and not the host compiler.
>
> Comparing the binaries is generally slower of course.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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. > > > > Note that the comparison we do with LTO bootstrap is quite pointless as we > > only compile the internal IL at LTO streaming time but not the final result > > of optimization. For that we'd need to compare cc1, cc1plus, etc. itself. > To call it pointless is as dismissive of the effort as saying you'd be > willing to accept any indeterministic behaviour, including magic, into > computer science as long as it produces great software. Let's not be this > lazy. I'm calling it pointless to motivate adding comparison of the optimized binaries themselves. I'm not arguing to remove bootstrap comparison completely - but maybe to remove LTO IL comparison if we got optimized binary comparison in exchange.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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. ***
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||9.2.0 Resolution|--- |FIXED --- Comment #71 from Richard Biener --- I think this was fixed with the introduction of contrib/compare-lto for GCC 9 (PR85571).
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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...
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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 from Richard Biener --- Bootstrap with LTO fails for me on the GCC 5 branch now as well (thus, with --enable-checking=release --enable-stage1-checking=yes).
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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 --- Comment #58 from vekumar at gcc dot gnu.org --- Richard, So for GCC 5.0 branch we has to use --enable-stage1-checking=release as workaround?
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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 |Added > > CC||vekumar at gcc dot gnu.org > > --- Comment #58 from vekumar at gcc dot gnu.org --- > Richard, > > So for GCC 5.0 branch we has to use --enable-stage1-checking=release as > workaround? I'm currently verifying if that works, yes.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 --- Comment #60 from Richard Biener --- Workaround confirmed for GCC 5 (--enable-stage1-checking=release).
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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 from Jakub Jelinek ---
(In reply to Richard Biener from comment #60)
> Workaround confirmed for GCC 5 (--enable-stage1-checking=release).
So, what about just use the workaround automatically for the default
--enable-stage1-checking (of course, if somebody uses something explicitly, he
is on his own)?
Like:
--- configure.ac.jj2015-03-27 18:32:41.0 +0100
+++ configure.ac2015-04-17 13:01:30.117314053 +0200
@@ -3482,7 +3482,19 @@ AC_ARG_ENABLE(stage1-checking,
[choose additional checking for stage1 of the compiler])],
[stage1_checking=--enable-checking=${enable_stage1_checking}],
[if test "x$enable_checking" = xno || test "x$enable_checking" = x; then
- stage1_checking=--enable-checking=yes,types
+ # For --disable-checking or implicit --enable-checking=release, avoid
+ # setting --enable-checking=gc in the default stage1 checking for LTO
+ # bootstraps. See PR62077.
+ stage1_checking=--enable-checking=release,misc,gimple,rtlflag,tree,types
+ case $BUILD_CONFIG in
+*lto*)
+ if test "x$enable_checking" = x && \
+ test -d ${srcdir}/gcc && \
+ test x"`cat ${srcdir}/gcc/DEV-PHASE`" = xexperimental; then
+stage1_checking=--enable-checking=yes,types
+ fi;;
+*) stage1_checking=--enable-checking=yes,types;;
+ esac
else
stage1_checking=--enable-checking=$enable_checking,types
fi])
I've so far successfully bootstrapped GCC 5 branch with
../configure --prefix=/tmp/blah --with-gnu-as --with-gnu-ld
--enable-languages=all,go --disable-multilib --disable-nls --with-arch=haswell
--with-tune=haswell --with-build-config=bootstrap-lto
--enable-stage1-checking=release,misc,gimple,rtlflag,tree,types
so it indeed is the gc checking that breaks the LTO bootstrap comparison.
release,misc,gimple,rtlflag,tree,types I believe enables everything yes,types
enables, except for gc checking.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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 :/
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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): Default to release,misc,gimple,rtlflag,tree,types if --disable-checking or --enable-checking is not specified and DEV-PHASE is not experimental. * configure: Regenerated. Modified: trunk/ChangeLog trunk/configure trunk/configure.ac
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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): Default to release,misc,gimple,rtlflag,tree,types if --disable-checking or --enable-checking is not specified and DEV-PHASE is not experimental. * configure: Regenerated. Modified: branches/gcc-5-branch/ChangeLog branches/gcc-5-branch/configure branches/gcc-5-branch/configure.ac
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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|lto |5.1.1 --- Comment #65 from H.J. Lu --- GCC 5 branch on Linux/x86-64 with --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --prefix=/usr/local --enable-gnu-indirect-function --disable-werror --with-build-config=bootstrap-lto --with-fpmath=sse I got gcc/except.o differs gcc/build/genconfig.o differs gcc/build/genpeep.o differs gcc/tree-cfg.o differs gcc/tree-ssa-loop-ivcanon.o differs gcc/tree-inline.o differs gcc/dbxout.o differs gcc/web.o differs gcc/sel-sched-ir.o differs gcc/reload1.o differs gcc/function.o differs gcc/tree-vrp.o differs gcc/tree-diagnostic.o differs gcc/dumpfile.o differs gcc/dwarf2cfi.o differs gcc/regcprop.o differs gcc/tree.o differs gcc/lto-streamer-out.o differs gcc/cfgexpand.o differs gcc/ipa-devirt.o differs gcc/tree-ssa-propagate.o differs gcc/ipa-inline-analysis.o differs gcc/java/lang.o differs gcc/java/expr.o differs gcc/tree-outof-ssa.o differs gcc/tree-eh.o differs gcc/emit-rtl.o differs gcc/cfgloop.o differs gcc/tree-ssa-pre.o differs gcc/cfgloopmanip.o differs gcc/lto-cgraph.o differs gcc/objc/objc-act.o differs gcc/varasm.o differs gcc/cp/pt.o differs gcc/cp/class.o differs gcc/cp/name-lookup.o differs gcc/cp/cp-gimplify.o differs gcc/cp/semantics.o differs gcc/cp/parser.o differs gcc/sched-rgn.o differs gcc/c/c-parser.o differs gcc/c/c-typeck.o differs gcc/gimple-low.o differs gcc/sel-sched.o differs gcc/tree-ssa-uninit.o differs gcc/coverage.o differs gcc/omp-low.o differs gcc/gimple.o differs gcc/c-family/c-ada-spec.o differs gcc/c-family/c-pragma.o differs gcc/dwarf2out.o differs gcc/tree-switch-conversion.o differs gcc/cfgrtl.o differs gcc/i386.o differs libcpp/lex.o differs
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
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 the object files matches then it should not matter much how it got there. It is not perfect, but it is better than not to bootstrap at all. I am going to attach a patch for those who are interested. Sven
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
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 --- Comment #2 from Sven C. Dack --- Created attachment 33285 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33285&action=edit Changes the way 'bootstrap-lto.mk' compares object files The patch changes how 'bootstrap-lto.mk' compares object files by adding a new script 'compare-disassembly', which only compares the disassembled output of two object files.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 Richard Biener changed: What|Removed |Added Keywords||build, lto Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-11 CC|richard.guenther at gmail dot com |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- Btw, I can confirm the issue for the 4.9 branch (with release checking).
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 Richard Biener changed: What|Removed |Added Target||x86_64-*-* --- Comment #4 from Richard Biener --- Also fails with the 4.9.0 release on x86_64.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
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.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
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-seed=1 -ffat-lto-objects ... to: ... STAGE2_CFLAGS += -flto=1 -flto-partition=none -frandom-seed=1 -ffat-lto-objects STAGE3_CFLAGS += -flto=1 -flto-partition=none -frandom-seed=1 -ffat-lto-objects ... Results in a success without using an additional compare script: ... Comparing stages 2 and 3 warning: gcc/cc1obj-checksum.o differs warning: gcc/cc1-checksum.o differs warning: gcc/cc1plus-checksum.o differs Comparison successful. ...
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 Sven C. Dack changed: What|Removed |Added Attachment #33285|0 |1 is obsolete|| --- Comment #7 from Sven C. Dack --- Created attachment 33299 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33299&action=edit Removes the use of the jobserver from bootstrap-lto.mk The patch changes bootstrap-lto.mk to use a single, unpartitioned stream instead of the jobserver.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
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 stream > instead of the jobserver. This patch makes sense from a reproducibility point of view too.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 Markus Trippelsdorf changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #9 from Markus Trippelsdorf --- (In reply to Andrew Pinski from comment #8) > (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 stream > > instead of the jobserver. > > This patch makes sense from a reproducibility point of view too. But it will increase the build-time enormously.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
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 |Added > > CC||trippels at gcc dot gnu.org > > --- Comment #9 from Markus Trippelsdorf --- > (In reply to Andrew Pinski from comment #8) > > (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 stream > > > instead of the jobserver. > > > > This patch makes sense from a reproducibility point of view too. > > But it will increase the build-time enormously. Yeah, and that it triggers a comparison error sounds bogus. It just triggers the use of a makefile for building the _LTRANS_ objects. Thus it shouldn't have an effect on the object files we compare (especially if the actual final cc1 object does _not_ miscompare and thus we don't see a stage2/3 miscompile). Richard.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
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 bisecting to see which revision fixes this (or) first time compare not seen. Also I tried to recompile gimple.o which was miscomparing and also dump the gimple and IPA IR. I found that in GCC trunk there are no differences between stage2 and stage3 dumps. But with GCC 4.9 there are some differences, Stage2 (prev-gcc) vs stage3 (gcc) Very first dump file is gimple.c.001t.tu The number of @numbers are more in stage2 @103184 identifier_node strg: debug_ready_dispatchlngt: 20 Stage3 @103169 identifier_node strg: debug_ready_dispatchlngt: 20 Also gimple.c.048i.inline showed differences in Min size. (--Snip--) < min size: 6 --- > min size: 0 6590c6590 < min size: 14 --- > min size: 0 6607c6607 < min size: 28 (--Snip--) In gimple-fold.c.000i.cgraph (--Snip--) < _Z25gimple_build_omp_continueP9tree_nodeS0_/761 (gimple_build_omp_continue(tree_node*, tree_node*)) @0x3ff7ebda548 --- > _Z25gimple_build_omp_continueP9tree_nodeS0_/761 > (gimple_build_omp_continue(tree_node*, tree_node*)) @0x3ff92b5a548 28865c28865 (--Snip--) why do these dumps show differences? The other tree optimization dumps don't show any difference.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
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 (!) we sort
via
static int
scc_entry_compare (const void *p1_, const void *p2_)
{
const scc_entry *p1 = (const scc_entry *) p1_;
const scc_entry *p2 = (const scc_entry *) p2_;
if (p1->hash < p2->hash)
return -1;
else if (p1->hash > p2->hash)
return 1;
return 0;
}
static hashval_t
hash_scc (struct streamer_tree_cache_d *cache, unsigned first, unsigned size)
{
/* Compute hash values for the SCC members. */
for (unsigned i = 0; i < size; ++i)
sccstack[first+i].hash = hash_tree (cache, sccstack[first+i].t);
if (size == 1)
return sccstack[first].hash;
/* Sort the SCC of type, hash pairs so that when we mix in
all members of the SCC the hash value becomes independent on
the order we visited the SCC. Disregard hashes equal to
the hash of the tree we mix into because we cannot guarantee
a stable sort for those across different TUs. */
qsort (&sccstack[first], size, sizeof (scc_entry), scc_entry_compare);
which means returning 0 from the qsort compare function for hash
collisions. In theory the qsort implementation can randomly permute
stuff here leading to comparison fails.
I'm checking if breaking the tie via the DFS number fixes the miscompare
I saw.
Note that I assumed that "sane" implementations would behave consistently
here, but of course with address-space randomization and friends and an
implementation that breaks tie itself via addresses would break.
(I'd choose a simpler tie breaker - first argument to compare is less
than second arg to compare).
Well. Not sure what glibc msort does here.
That said, the smallest object I observe differences is build/genconfig.o
which has differences in the size(!) of the LTO_section_decls section
and differences already in the decl-state refs part.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
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.
>
> Especially I'm talking about the fact that at compile-time (!) we sort
> via
>
> static int
> scc_entry_compare (const void *p1_, const void *p2_)
> {
> const scc_entry *p1 = (const scc_entry *) p1_;
> const scc_entry *p2 = (const scc_entry *) p2_;
> if (p1->hash < p2->hash)
> return -1;
> else if (p1->hash > p2->hash)
> return 1;
> return 0;
> }
>
> static hashval_t
> hash_scc (struct streamer_tree_cache_d *cache, unsigned first, unsigned size)
> {
> /* Compute hash values for the SCC members. */
> for (unsigned i = 0; i < size; ++i)
> sccstack[first+i].hash = hash_tree (cache, sccstack[first+i].t);
>
> if (size == 1)
> return sccstack[first].hash;
>
> /* Sort the SCC of type, hash pairs so that when we mix in
> all members of the SCC the hash value becomes independent on
> the order we visited the SCC. Disregard hashes equal to
> the hash of the tree we mix into because we cannot guarantee
> a stable sort for those across different TUs. */
> qsort (&sccstack[first], size, sizeof (scc_entry), scc_entry_compare);
>
> which means returning 0 from the qsort compare function for hash
> collisions. In theory the qsort implementation can randomly permute
> stuff here leading to comparison fails.
>
> I'm checking if breaking the tie via the DFS number fixes the miscompare
> I saw.
>
> Note that I assumed that "sane" implementations would behave consistently
> here, but of course with address-space randomization and friends and an
> implementation that breaks tie itself via addresses would break.
> (I'd choose a simpler tie breaker - first argument to compare is less
> than second arg to compare).
>
> Well. Not sure what glibc msort does here.
>
> That said, the smallest object I observe differences is build/genconfig.o
> which has differences in the size(!) of the LTO_section_decls section
> and differences already in the decl-state refs part.
Doesn't help. The list of miscompared files seems to be reproducible at least,
but the actual file contents are different for two compiles.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
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-lto-objects > STAGE3_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects > ... > > to: > > ... > STAGE2_CFLAGS += -flto=1 -flto-partition=none -frandom-seed=1 > -ffat-lto-objects > STAGE3_CFLAGS += -flto=1 -flto-partition=none -frandom-seed=1 > -ffat-lto-objects > ... > > Results in a success without using an additional compare script: > > ... > Comparing stages 2 and 3 > warning: gcc/cc1obj-checksum.o differs > warning: gcc/cc1-checksum.o differs > warning: gcc/cc1plus-checksum.o differs > Comparison successful. > ... 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 amd64 machine. But still getting compare errors with GCC 4.9 branch. The HEAD is at revision 213070.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
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 > amd64 machine. But still getting compare errors with GCC 4.9 branch. The > HEAD is at revision 213070. I have noticed a typo in one of my build scripts later this morning and am now trying to verify the result. It is still not done yet. If it is indeed wrong then I am going to take out the second patch. I am also trying to use a "1to1" partition together with -flto=jobserver and want to see if this makes a difference. This, too, is not done yet. On a different note, I have managed to build a working compiler yesterday using my compare-disassembly script with: --with-build-config=bootstrap-lto --with-boot-ldflags=-fuse-linker-plugin I am still in the process of verifying it and running tests to see if I run into any problems with it, but so far am I excited to have gotten this far. gmp, mpfr and mpc have all been compiled with LTO enabled and have run their testsuits without an error. I have tried pushing it further with "-fipa-pta -fuse-liner-plugin", but ran out of memory (>16GB).
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
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 written from ipa_write_jump_function 4237case IPA_JF_CONST: 4238 gcc_assert ( 4239 EXPR_LOCATION (jump_func->value.constant.value) == UNKNOWN_LOCATION); 4240 stream_write_tree (ob, jump_func->value.constant.value, true); 4241 break; as &"#endif"[0] Its type main variant is built in c-family/c-common.c:1021 and the literal itself in builtins.c:13383. And we indeed get differences in inline_param2 (min size), otherwise no visible differences anywhere in dumps. Not sure how that can explain the type difference for the jump function though... Again, this is build/genconfig.o as compiled by stage1 cc1plus vs. stage2 cc1plus (so faster to reproduce / bisect).
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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 |ap-lto fails, |ap-lto fails --- Comment #17 from Sven C. Dack --- I have tested several command line options to see if these change anything, but they all give the exact same comparison failures (same files and in the same ordering): -flto=jobserver -flto-partition=1to1 -flto=jobserver -flto-partition=none -flto=1 -flto-partition=none
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 Sven C. Dack changed: What|Removed |Added Attachment #33299|0 |1 is obsolete|| --- Comment #18 from Sven C. Dack --- Created attachment 33310 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33310&action=edit Work-around: changes the way bootstrap-lto.mk compares object files The patch changes the way bootstrap-lto.mk compares object files during the comparison of stage 2 and 3 by only comparing the disassembled code. It works around situations where a possibly correct compiler can be produced while it still has differences in their object files. This also reverts the last patch, which was based on a false positive.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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) and stage3 build/genconfig.o with -flto (using the stage2 compiler) and observe the exact same differences. Without IPA-CP the difference in genconfig.o just jumps to a later place. I'm quite sure the difference in the string literal type also occurs without -flto but I don't see an easy way to verify that(?) Maybe this is all spurious with host compiler capabilities leaking into the IL in some way (not affecting code generation by luck). - I'm testing if trunk is really not affected (with --enable-checking=release). - We need to track down that min_size issue sawn (but it looks unrelated)
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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 > build/genconfig.o with -flto (using > the stage1 compiler) and stage3 build/genconfig.o with -flto (using the > stage2 > compiler) and observe the exact same differences. > > Without IPA-CP the difference in genconfig.o just jumps to a later place. > I'm quite sure the difference in the string literal type also occurs > without -flto but I don't see an easy way to verify that(?) > > Maybe this is all spurious with host compiler capabilities leaking into > the IL in some way (not affecting code generation by luck). > > - I'm testing if trunk is really not affected (with > --enable-checking=release). It indeed works. Back to the question what fixed it ... > - We need to track down that min_size issue sawn (but it looks unrelated)
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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 +59,8 @@ along with GCC; see the file COPYING3.
#include "builtins.h"
#include "ubsan.h"
#include "cilk.h"
+#include "dumpfile.h"
+#include "tree-pretty-print.h"
static tree do_mpc_arg1 (tree, tree, int (*)(mpc_ptr, mpc_srcptr, mpc_rnd_t));
@@ -4695,6 +4697,15 @@ build_string_literal (int len, const cha
elem = build_type_variant (char_type_node, 1, 0);
index = build_index_type (size_int (len - 1));
type = build_array_type (elem, index);
+ fprintf (stderr, "%s <%p> ", str, (void *)type);
+ print_generic_expr (stderr, type, TDF_SLIM);
+ if (TYPE_MAIN_VARIANT (type) == type)
+;
+ else
+{
+ fprintf (stderr, " <%p> ", (void *)TYPE_MAIN_VARIANT (type));
+ print_generic_expr (stderr, TYPE_MAIN_VARIANT (type), TDF_SLIM);
+}
+ fprintf (stderr, "\n");
TREE_TYPE (t) = type;
TREE_CONSTANT (t) = 1;
TREE_READONLY (t) = 1;
then I get for building non-LTO stage2 build/genconfig.o
#ifndef MAX_INSNS_PER_SPLIT
<0x75af4e70> const char[28]
#endif
<0x75af6000> const char[7]
#define HAVE_cc0 1
<0x75af6150> const char[19]
#define CC0_P(X) ((X) == cc0_rtx)
<0x75af62a0> const char[34]
#define CC0_P(X) ((X) ? 0 : 0)
<0x75aef540> const char[31] <0x75aef498> char[31]
#define HAVE_conditional_move 1
<0x75aefe70> const char[32] <0x75de6d20> char[32]
#define HAVE_conditional_execution 1
<0x75af6690> const char[37]
#define HAVE_lo_sum 1
<0x75af67e0> const char[22]
#define HAVE_peephole 1
<0x75af6930> const char[24]
#define HAVE_peephole2 1
<0x75af45e8> const char[25] <0x75af4540> char[25]
and for stage3:
#ifndef MAX_INSNS_PER_SPLIT
<0x75db9150> const char[28]
#endif
<0x7601bc78> const char[7] <0x7601bbd0> char[7]
#define HAVE_cc0 1
<0x75db93f0> const char[19]
#define CC0_P(X) ((X) == cc0_rtx)
<0x75db9540> const char[34]
#define CC0_P(X) ((X) ? 0 : 0)
<0x75db17e0> const char[31] <0x75db1738> char[31]
#define HAVE_conditional_move 1
<0x75db4150> const char[32] <0x76017888> char[32]
#define HAVE_conditional_execution 1
<0x75db9930> const char[37]
#define HAVE_lo_sum 1
<0x75db9a80> const char[22]
#define HAVE_peephole 1
<0x75db9bd0> const char[24]
#define HAVE_peephole2 1
<0x75db5888> const char[25] <0x75db57e0> char[25]
so whether the #endif literal has a TYPE_MAIN_VARIANT or not changes.
Which means in one case somebody builds that very same array type
earlier.
Instrumenting build_array_type I see that stage3 doesn't build some
types stage2 builds. Weird.
Ah. Well - type_hash_table is marked as GC-able thus when using the
stage1 compiler we run with --param ggc-min-expand=30 --param
ggc-min-heapsize=4096 but when using the stage2 compiler we use
--param ggc-min-expand=100 --param ggc-min-heapsize=131072.
using the same --param settings for stage2 fixes this difference
(but not fully the miscompare in the LTO object).
But this _is_ an issue for reproducability of LTO IL (and types
in general).
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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 (revision 213814)
> +++ builtins.c (working copy)
> @@ -59,6 +59,8 @@ along with GCC; see the file COPYING3.
> #include "builtins.h"
> #include "ubsan.h"
> #include "cilk.h"
> +#include "dumpfile.h"
> +#include "tree-pretty-print.h"
>
>
> static tree do_mpc_arg1 (tree, tree, int (*)(mpc_ptr, mpc_srcptr,
> mpc_rnd_t));
> @@ -4695,6 +4697,15 @@ build_string_literal (int len, const cha
>elem = build_type_variant (char_type_node, 1, 0);
>index = build_index_type (size_int (len - 1));
>type = build_array_type (elem, index);
> + fprintf (stderr, "%s <%p> ", str, (void *)type);
> + print_generic_expr (stderr, type, TDF_SLIM);
> + if (TYPE_MAIN_VARIANT (type) == type)
> +;
> + else
> +{
> + fprintf (stderr, " <%p> ", (void *)TYPE_MAIN_VARIANT (type));
> + print_generic_expr (stderr, TYPE_MAIN_VARIANT (type), TDF_SLIM);
> +}
> + fprintf (stderr, "\n");
>TREE_TYPE (t) = type;
>TREE_CONSTANT (t) = 1;
>TREE_READONLY (t) = 1;
>
>
> then I get for building non-LTO stage2 build/genconfig.o
>
> #ifndef MAX_INSNS_PER_SPLIT
> <0x75af4e70> const char[28]
> #endif
> <0x75af6000> const char[7]
> #define HAVE_cc0 1
> <0x75af6150> const char[19]
> #define CC0_P(X) ((X) == cc0_rtx)
> <0x75af62a0> const char[34]
> #define CC0_P(X) ((X) ? 0 : 0)
> <0x75aef540> const char[31] <0x75aef498> char[31]
> #define HAVE_conditional_move 1
> <0x75aefe70> const char[32] <0x75de6d20> char[32]
> #define HAVE_conditional_execution 1
> <0x75af6690> const char[37]
> #define HAVE_lo_sum 1
> <0x75af67e0> const char[22]
> #define HAVE_peephole 1
> <0x75af6930> const char[24]
> #define HAVE_peephole2 1
> <0x75af45e8> const char[25] <0x75af4540> char[25]
>
> and for stage3:
>
> #ifndef MAX_INSNS_PER_SPLIT
> <0x75db9150> const char[28]
> #endif
> <0x7601bc78> const char[7] <0x7601bbd0> char[7]
> #define HAVE_cc0 1
> <0x75db93f0> const char[19]
> #define CC0_P(X) ((X) == cc0_rtx)
> <0x75db9540> const char[34]
> #define CC0_P(X) ((X) ? 0 : 0)
> <0x75db17e0> const char[31] <0x75db1738> char[31]
> #define HAVE_conditional_move 1
> <0x75db4150> const char[32] <0x76017888> char[32]
> #define HAVE_conditional_execution 1
> <0x75db9930> const char[37]
> #define HAVE_lo_sum 1
> <0x75db9a80> const char[22]
> #define HAVE_peephole 1
> <0x75db9bd0> const char[24]
> #define HAVE_peephole2 1
> <0x75db5888> const char[25] <0x75db57e0> char[25]
>
> so whether the #endif literal has a TYPE_MAIN_VARIANT or not changes.
> Which means in one case somebody builds that very same array type
> earlier.
>
> Instrumenting build_array_type I see that stage3 doesn't build some
> types stage2 builds. Weird.
>
> Ah. Well - type_hash_table is marked as GC-able thus when using the
> stage1 compiler we run with --param ggc-min-expand=30 --param
> ggc-min-heapsize=4096 but when using the stage2 compiler we use
> --param ggc-min-expand=100 --param ggc-min-heapsize=131072.
>
> using the same --param settings for stage2 fixes this difference
> (but not fully the miscompare in the LTO object).
Now a difference is only in .shstrtab (huh?). Ah, from the differences
in section name due to hashing them (too lame reproducer).
So making GC behave the same for the stage1 compiler and the stage2
compiler fixes things.
trying
Index: config/bootstrap-lto.mk
===
--- config/bootstrap-lto.mk (revision 213899)
+++ config/bootstrap-lto.mk (working copy)
@@ -2,6 +2,6 @@
# FIXME: Our build system is not yet able to use gcc-ar wrapper, so we need
# to go with -ffat-lto-objects.
-STAGE2_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects
-STAGE3_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects
+STAGE2_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects --param
ggc-min-expand=100 --param ggc-min-heapsize=131072
+STAGE3_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects --param
ggc-min-expand=100 --param ggc-min-heapsize=131072
STAGEprofile_CFLAGS += -fno-lto
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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) @@ -6593,7 +6593,9 @@ type_hash_eq (const void *va, const void || !attribute_list_equal (TYPE_ATTRIBUTES (a->type), TYPE_ATTRIBUTES (b->type)) || (TREE_CODE (a->type) != COMPLEX_TYPE - && TYPE_NAME (a->type) != TYPE_NAME (b->type))) + && TYPE_NAME (a->type) != TYPE_NAME (b->type)) + || ((TYPE_MAIN_VARIANT (a->type) == TYPE_MAIN_VARIANT (a->type)) + != (TYPE_MAIN_VARIANT (b->type) == TYPE_MAIN_VARIANT (b->type return 0; /* Be careful about comparing arrays before and after the element type
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #25 from Richard Biener --- Patch in testing.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
Richard Biener changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #26 from Richard Biener ---
(In reply to Richard Biener from comment #24)
> Or "real" fix for the type_hash_canon issue (untested)
>
> Index: gcc/tree.c
> ===
> --- gcc/tree.c (revision 213814)
> +++ gcc/tree.c (working copy)
> @@ -6593,7 +6593,9 @@ type_hash_eq (const void *va, const void
>|| !attribute_list_equal (TYPE_ATTRIBUTES (a->type),
> TYPE_ATTRIBUTES (b->type))
>|| (TREE_CODE (a->type) != COMPLEX_TYPE
> - && TYPE_NAME (a->type) != TYPE_NAME (b->type)))
> + && TYPE_NAME (a->type) != TYPE_NAME (b->type))
> + || ((TYPE_MAIN_VARIANT (a->type) == TYPE_MAIN_VARIANT (a->type))
> + != (TYPE_MAIN_VARIANT (b->type) == TYPE_MAIN_VARIANT (b->type
> return 0;
>
>/* Be careful about comparing arrays before and after the element type
Hmpf, that doesn't fix it. But the following makes us ICE:
Index: tree.c
===
--- tree.c (revision 213814)
+++ tree.c (working copy)
@@ -6759,6 +6761,7 @@ type_hash_canon (unsigned int hashcode,
t1 = type_hash_lookup (hashcode, type);
if (t1 != 0)
{
+ gcc_assert (TYPE_MAIN_VARIANT (t1) == t1);
if (GATHER_STATISTICS)
{
tree_code_counts[(int) TREE_CODE (type)]--;
which means somebody mangles TYPE_MAIN_VARIANT of a type already in
the type hash table.
build_cplus_array_type is it:
/* We want TYPE_MAIN_VARIANT of an array to strip cv-quals from the
element type as well, so fix it up if needed. */
if (elt_type != TYPE_MAIN_VARIANT (elt_type))
{
tree m = build_cplus_array_type (TYPE_MAIN_VARIANT (elt_type),
index_type);
...
TYPE_MAIN_VARIANT (t) = m;
Jason? Something like
Index: cp/tree.c
===
--- cp/tree.c (revision 213814)
+++ cp/tree.c (working copy)
@@ -824,7 +824,11 @@ build_cplus_array_type (tree elt_type, t
build_cplus_array_type
(TYPE_CANONICAL (elt_type),
index_type ? TYPE_CANONICAL (index_type) : index_type);
- t = build_array_type (elt_type, index_type);
+ if (elt_type != TYPE_MAIN_VARIANT (elt_type))
+ t = build_cplus_array_type (TYPE_MAIN_VARIANT (elt_type),
+ index_type);
+ else
+ t = build_array_type (elt_type, index_type);
}
/* Push these needs up so that initialization takes place
@@ -840,37 +844,19 @@ build_cplus_array_type (tree elt_type, t
element type as well, so fix it up if needed. */
if (elt_type != TYPE_MAIN_VARIANT (elt_type))
{
- tree m = build_cplus_array_type (TYPE_MAIN_VARIANT (elt_type),
- index_type);
-
- if (TYPE_MAIN_VARIANT (t) != m)
+ /* ??? We didn't even try to re-use existing types?
+ ??? Ah, we did via the type_hash_canon that this breaks. */
+ tree t1;
+ for (t1 = TYPE_MAIN_VARIANT (t); t1; t1 = TYPE_NEXT_VARIANT (t1))
+ if (TREE_TYPE (t1) == elt_type)
+ {
+ t = t1;
+ break;
+ }
+ if (!t1)
{
- if (COMPLETE_TYPE_P (TREE_TYPE (t)) && !COMPLETE_TYPE_P (m))
- {
- /* m was built before the element type was complete, so we
-also need to copy the layout info from t. We might
-end up doing this multiple times if t is an array of
-unknown bound. */
- tree size = TYPE_SIZE (t);
- tree size_unit = TYPE_SIZE_UNIT (t);
- unsigned int align = TYPE_ALIGN (t);
- unsigned int user_align = TYPE_USER_ALIGN (t);
- enum machine_mode mode = TYPE_MODE (t);
- for (tree var = m; var; var = TYPE_NEXT_VARIANT (var))
- {
- TYPE_SIZE (var) = size;
- TYPE_SIZE_UNIT (var) = size_unit;
- TYPE_ALIGN (var) = align;
- TYPE_USER_ALIGN (var) = user_align;
- SET_TYPE_MODE (var, mode);
- TYPE_NEEDS_CONSTRUCTING (var) = needs_ctor;
- TYPE_HAS_NONTRIVIAL_DESTRUCTOR (var) = needs_dtor;
- }
- }
-
- TYPE_MAIN_VARIANT (t) = m;
- TYPE_NEXT_VARIANT (t) = TYPE_NEXT_VARIANT (m);
- TYPE_NEXT_VARIANT (m) = t;
+ t = build_variant_type_copy (t);
+ TREE_TYPE (t) = elt_type;
}
}
fixes that - but eventually breaks whatever needed that odd type completion,
which we also can't allow on types that are recorded in
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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/tree.c (revision 213814) > +++ gcc/tree.c (working copy) > @@ -6593,7 +6593,9 @@ type_hash_eq (const void *va, const void >|| !attribute_list_equal (TYPE_ATTRIBUTES (a->type), > TYPE_ATTRIBUTES (b->type)) >|| (TREE_CODE (a->type) != COMPLEX_TYPE > - && TYPE_NAME (a->type) != TYPE_NAME (b->type))) > + && TYPE_NAME (a->type) != TYPE_NAME (b->type)) > + || ((TYPE_MAIN_VARIANT (a->type) == TYPE_MAIN_VARIANT (a->type)) > + != (TYPE_MAIN_VARIANT (b->type) == TYPE_MAIN_VARIANT (b->type > return 0; > >/* Be careful about comparing arrays before and after the element type This looks wrong. It looks like you are doing "... || ((true) != (true))".
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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 I will try adding --param ggc-min-expand=100 --param ggc-min-heapsize=131072 to stage2 and stage3 flags.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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 > > I am still getting same number of compare errors. > > Now I will try adding --param ggc-min-expand=100 --param > ggc-min-heapsize=131072 to stage2 and stage3 flags. I am getting more compare errors in Aarch64 machine in this case. aarch64-unknown-linux-gnu/libgcc/_fixunsxfsi.o differs aarch64-unknown-linux-gnu/libgcc/_fixxfdi_s.o differs aarch64-unknown-linux-gnu/libgcc/_fixunsxfsi_s.o differs aarch64-unknown-linux-gnu/libgcc/_ctors_s.o differs aarch64-unknown-linux-gnu/libgcc/_floatdixf.o differs aarch64-unknown-linux-gnu/libgcc/_popcount_tab_s.o differs aarch64-unknown-linux-gnu/libgcc/_powixf2.o differs aarch64-unknown-linux-gnu/libgcc/unwind-sjlj.o differs aarch64-unknown-linux-gnu/libgcc/unwind-sjlj_s.o differs aarch64-unknown-linux-gnu/libgcc/crtendS.o differs gcc/sdbout.o differs gcc/c/c-lang.o differs gcc/graphite-poly.o differs gcc/graphite-dependences.o differs gcc/crtend.o differs gcc/vmsdbgout.o differs gcc/hw-doloop.o differs gcc/graphite-optimize-isl.o differs gcc/version.o differs gcc/target-globals.o differs gcc/graphite-interchange.o differs gcc/collect2-aix.o differs gcc/graphite-scop-detection.o differs gcc/loop-doloop.o differs gcc/graphite-blocking.o differs gcc/graphite-clast-to-gimple.o differs gcc/build/min-insn-modes.o differs gcc/build/version.o differs gcc/graphite-sese-to-poly.o differs gcc/insn-peep.o differs gcc/insn-enums.o differs gcc/xcoffout.o differs gcc/crtendS.o differs libbacktrace/atomic.o differs libiberty/pic/safe-ctype.o differs libiberty/pic/getopt.o differs libiberty/pic/obstack.o differs libiberty/pic/fnmatch.o differs libiberty/pic/getopt1.o differs libiberty/safe-ctype.o differs libiberty/getopt.o differs libiberty/obstack.o differs libiberty/fnmatch.o differs libiberty/getopt1.o differs I will try to test the patch on x86_64 machine now.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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/ml/gcc-patches/2014-08/msg01324.html > > > > I am still getting same number of compare errors. > > > > Now I will try adding --param ggc-min-expand=100 --param > > ggc-min-heapsize=131072 to stage2 and stage3 flags. > > I am getting more compare errors in Aarch64 machine in this case. > aarch64-unknown-linux-gnu/libgcc/_fixunsxfsi.o differs > aarch64-unknown-linux-gnu/libgcc/_fixxfdi_s.o differs > aarch64-unknown-linux-gnu/libgcc/_fixunsxfsi_s.o differs > aarch64-unknown-linux-gnu/libgcc/_ctors_s.o differs > aarch64-unknown-linux-gnu/libgcc/_floatdixf.o differs > aarch64-unknown-linux-gnu/libgcc/_popcount_tab_s.o differs > aarch64-unknown-linux-gnu/libgcc/_powixf2.o differs > aarch64-unknown-linux-gnu/libgcc/unwind-sjlj.o differs > aarch64-unknown-linux-gnu/libgcc/unwind-sjlj_s.o differs > aarch64-unknown-linux-gnu/libgcc/crtendS.o differs > gcc/sdbout.o differs > gcc/c/c-lang.o differs > gcc/graphite-poly.o differs > gcc/graphite-dependences.o differs > gcc/crtend.o differs > gcc/vmsdbgout.o differs > gcc/hw-doloop.o differs > gcc/graphite-optimize-isl.o differs > gcc/version.o differs > gcc/target-globals.o differs > gcc/graphite-interchange.o differs > gcc/collect2-aix.o differs > gcc/graphite-scop-detection.o differs > gcc/loop-doloop.o differs > gcc/graphite-blocking.o differs > gcc/graphite-clast-to-gimple.o differs > gcc/build/min-insn-modes.o differs > gcc/build/version.o differs > gcc/graphite-sese-to-poly.o differs > gcc/insn-peep.o differs > gcc/insn-enums.o differs > gcc/xcoffout.o differs > gcc/crtendS.o differs > libbacktrace/atomic.o differs > libiberty/pic/safe-ctype.o differs > libiberty/pic/getopt.o differs > libiberty/pic/obstack.o differs > libiberty/pic/fnmatch.o differs > libiberty/pic/getopt1.o differs > libiberty/safe-ctype.o differs > libiberty/getopt.o differs > libiberty/obstack.o differs > libiberty/fnmatch.o differs > libiberty/getopt1.o differs > > > I will try to test the patch on x86_64 machine now. Richard, I thought I used existing build directory for the patch test. So did another build with gcc 4.9 + garbage collector tuning flags for stage2/3 on Aarch64. (Snip) STAGE2_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects --param ggc-min-expand=100 --param ggc-min-heapsize=131072 STAGE3_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects --param ggc-min-expand=100 --param ggc-min-heapsize=131072 (Snip) Bootstrap passes cleanly.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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 bootstrap but makes build/genconfig.o no longer to miscompare Thus we seem to have a multitude of GC-related "IL" differences. Ugh.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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> [1970] = identifier_node <0x76706210> [1971] = tree_list <0x76703af0> [1972] = tree_list <0x76703c30> [1973] = tree_list <0x76707488> [1974] = tree_list <0x767861b8> [1975] = tree_list <0x767861e0> [1976] = tree_list <0x74dddaf0> [1977] = tree_list <0x74dddac8> [1978] = function_type <0x74de05e8> [1979] = identifier_node <0x76781840> [1980] = function_decl <0x76784d00> while stage3 [1968] = tree_list <0x76703ac8> [1969] = identifier_node <0x766ddf20> [1970] = identifier_node <0x76706210> [1971] = tree_list <0x76703af0> [1972] = tree_list <0x76703c30> [1973] = tree_list <0x76707488> [1974] = tree_list <0x767861b8> [1975] = tree_list <0x767861e0> [1976] = function_type <0x74de05e8> [1977] = identifier_node <0x76781840> [1978] = function_decl <0x76784d00> the tree_list differences come from stage2 streaming TYPE_ARG_TYPEs while stage3 producing a reference to previously written ones (streamed for __gmp_fprintf). Note that stage3 re-uses (aka shares) TYPE_ARG_TYPEs for fprintf and __gmp_fprintf while stage2 does not (the FUNCTION_TYPE itself is not shared). I don't even see where we would share TYPE_ARG_TYPEs but not the FUNCTION_TYPE itself... maybe it happens when parsing first builds a function type without attributes and then later appends attributes to them?
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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?
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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 that instead of using tune flags for garbage > collection, need to try and fix the object code differences? Yes, it points at real bugs. OTOH fixing that may not be suitable for the release branches, neither is passing fixed values for GC parameters. So I'm not quite sure what a suitable workaround is (well, make sure !defined ENABLE_GC_CHECKING && !defined ENABLE_GC_ALWAYS_COLLECT is consistent between stage1 and stage2 for bootstrap-lto, that is, init_ggc_heuristics () is executed in the same way)
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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 Venkataramanan > > --- > > Richard, What I understand is that instead of using tune flags for garbage > > collection, need to try and fix the object code differences? > > Yes, it points at real bugs. OTOH fixing that may not be suitable > for the release branches, neither is passing fixed values for GC > parameters. So I'm not quite sure what a suitable workaround is > (well, make sure !defined ENABLE_GC_CHECKING && !defined > ENABLE_GC_ALWAYS_COLLECT is consistent between stage1 and stage2 > for bootstrap-lto, that is, init_ggc_heuristics () is executed > in the same way) Or better yet recommend with LTO bootstrap, bootstrap4.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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 (working copy) > @@ -2,6 +2,6 @@ > # FIXME: Our build system is not yet able to use gcc-ar wrapper, so we need > # to go with -ffat-lto-objects. > > -STAGE2_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects > -STAGE3_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects > +STAGE2_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects --param > ggc-min-expand=100 --param ggc-min-heapsize=131072 > +STAGE3_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects --param > ggc-min-expand=100 --param ggc-min-heapsize=131072 > STAGEprofile_CFLAGS += -fno-lto It works for me, too. It has compiled 4.9.2-20140806 --with-build-config=bootstrap-lto and --with-boot-ldflags="-fuse-linker-plugin" successfully. It is now running the testsuite.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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 unexpected successes2 # of expected failures443 # of expected passes9246 # of unexpected failures6 # of expected failures41 # of expected passes689 # of expected passes26 # of expected failures3 # of expected passes54 Only 13 unexpected results, but these might be in there with or without LTO. I have not crossed checked it against a standard bootstrap yet.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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 expected passes 87886 > # of unexpected failures 2 > # of unexpected successes 2 > # of expected failures443 > # of expected passes 9246 > # of unexpected failures 6 > # of expected failures41 > # of expected passes 689 > # of expected passes 26 > # of expected failures3 > # of expected passes 54 > > Only 13 unexpected results, but these might be in there with or without LTO. > I have not crossed checked it against a standard bootstrap yet. The testsuite gives identical numbers of expected and unexpected results for a non-LTO build with 4.9.2-20140806. I am going to sit back now. Let me know if there is something I can do for you. Sven $ uname -a Linux debian-linux 3.14.17-sven #1 SMP Thu Aug 14 10:54:21 BST 2014 x86_64 GNU/Linux $ gcc --version gcc (GCC) 4.9.2 20140806 (prerelease) Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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 gcc's are: CFLAGS='-pipe -O2 -march=native -fomit-frame-pointer -fno-builtin-memcmp' default: configure ... make bootstrap profiled: configure ... make profiledbootstrap lto: configure ... --with-build-config=bootstrap-lto make bootstrap lto-plugin: configure ... --with-build-config=bootstrap-lto --with-boot-ldflags="-fuse-linker-plugin" make bootstrap The results are the averages (and deviations) of 5 runs with each compiler: avg stdev % default:282.86s0.56s, 0.20%100.00% (base) profiled: 255.76s0.72s, 0.28%+10.60% lto:282.80s0.16s, 0.06% +0.02% lto-plugin: 285.41s0.49s, 0.17% -0.89% The file sizes of the cc1's are: default:84920k profiled: 90176k lto:71204k lto-plugin: 60024k So boot strapping with LTO does not make gcc faster, but only smaller and also takes more time. It is almost as if I had used -Os (and not -O2). 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: default cc1: libmpc.so.3 => /home/sven/gcc-default/lib/libmpc.so.3 libmpfr.so.4 => /home/sven/gcc-default/lib/libmpfr.so.4 libgmp.so.10 => /home/sven/gcc-default/lib/libgmp.so.10 profiled cc1: libmpc.so.3 => /home/sven/gcc-profiled/lib/libmpc.so.3 libmpfr.so.4 => /home/sven/gcc-profiled/lib/libmpfr.so.4 libgmp.so.10 => /home/sven/gcc-profiled/lib/libgmp.so.10 lto cc1: libmpc.so.3 => /home/sven/gcc-lto/lib/libmpc.so.3 libmpfr.so.4 => /home/sven/gcc-lto/lib/libmpfr.so.4 libgmp.so.10 => /home/sven/gcc-lto/lib/libgmp.so.10 lto-plugin cc1: libmpc.so.3 => /home/sven/gcc-lto-plugin/lib/libmpc.so.3 libmpfr.so.4 => /home/sven/gcc-lto-plugin/lib/libmpfr.so.4 libgmp.so.10 => /home/sven/gcc-lto-plugin/lib/libgmp.so.10 libstdc++.so.6 => /home/sven/gcc-lto-plugin/lib64/libstdc++.so.6 libgcc_s.so.1 => /home/sven/gcc-lto-plugin/lib64/libgcc_s.so.1 I will try doing the same but with statically linked compilers.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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 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 gcc's are: > > CFLAGS='-pipe -O2 -march=native -fomit-frame-pointer -fno-builtin-memcmp' > > default: > configure ... > make bootstrap > > profiled: > configure ... > make profiledbootstrap > > lto: > configure ... --with-build-config=bootstrap-lto > make bootstrap > > lto-plugin: > configure ... --with-build-config=bootstrap-lto > --with-boot-ldflags="-fuse-linker-plugin" > make bootstrap > > The results are the averages (and deviations) of 5 runs with each compiler: > > avg stdev % > default:282.86s0.56s, 0.20%100.00% (base) > profiled: 255.76s0.72s, 0.28%+10.60% > lto:282.80s0.16s, 0.06% +0.02% > lto-plugin: 285.41s0.49s, 0.17% -0.89% > > The file sizes of the cc1's are: > > default:84920k > profiled: 90176k > lto:71204k > lto-plugin: 60024k > > So boot strapping with LTO does not make gcc faster, but only smaller and also > takes more time. It is almost as if I had used -Os (and not -O2). Most interesting is bootstrap-lto and make profiledbootstrap. > 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 be the default if you have recent enough binutils. Richard
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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.56s, 0.20%100.00% (base) > profiled: 255.76s0.72s, 0.28%+10.60% > lto:282.80s0.16s, 0.06% +0.02% > lto-plugin: 285.41s0.49s, 0.17% -0.89% Can you also try profiled+lto? This should in theory get you the fastes compiler.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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 stdev % > > default:282.86s0.56s, 0.20%100.00% (base) > > profiled: 255.76s0.72s, 0.28%+10.60% > > lto:282.80s0.16s, 0.06% +0.02% > > lto-plugin: 285.41s0.49s, 0.17% -0.89% > > Can you also try profiled+lto? This should in theory get you the fastes > compiler. I am already on it, but it will take a while. I had assumed this would not work yet. I also read that with only LTO one would get a faster compiler. Why is this not the case here? The binutils I am using are: $ ld --version GNU ld (GNU Binutils) 2.24.51.20140703 Copyright (C) 2014 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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 runs with each > > > compiler: > > > > > > avg stdev % > > > default:282.86s0.56s, 0.20%100.00% (base) > > > profiled: 255.76s0.72s, 0.28%+10.60% > > > lto:282.80s0.16s, 0.06% +0.02% > > > lto-plugin: 285.41s0.49s, 0.17% -0.89% > > > > Can you also try profiled+lto? This should in theory get you the fastes > > compiler. > > I am already on it, but it will take a while. > > I had assumed this would not work yet. I also read that with only LTO one > would get a faster compiler. Not in my experience. As you've found out LTO is good for reducing binary sizes, but it really needs PGO to make sensible decisions. BTW if you have TCMalloc installed on your machine, appending "POSTSTAGE1_LDFLAGS += -l/usr/lib/libtcmalloc.so.4" to config/bootstrap-lto.mk may give you an additional 8-10% speed boost (at least for big C++ projects, I haven't measured kernel build times).
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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 assert. gcc/cp/ * tree.c (build_min_array_type, set_array_type_canon): Split out... (build_cplus_array_type): ...from here. Only call build_array_type for main variants. Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c trunk/gcc/tree.c
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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.80s0.16s, 0.06% +0.02% > > > > lto-plugin: 285.41s0.49s, 0.17% -0.89% > ... > Not in my experience. As you've found out LTO is good for reducing > binary sizes, but it really needs PGO to make sensible decisions. These are the new results (5 runs). I have dropped "lto-plugin" and added "profiled-lto": avg stdev % default: 282.13s0.71, 0.25%100.00% (base) profiled: 255.29s0.80, 0.31%+10.52% lto: 281.71s0.70, 0.25% +0.15% profiled-lto: 251.38s0.49, 0.19%+12.23% gmp, mpfr and mpc have been compiled without LTO. > BTW if you have TCMalloc installed on your machine, appending > "POSTSTAGE1_LDFLAGS += -l/usr/lib/libtcmalloc.so.4" to > config/bootstrap-lto.mk > may give you an additional 8-10% speed boost (at least for big C++ projects, > I haven't measured kernel build times). This is going off the topic, but I do not mean to disrespect you. I did not use it in the test runs. You may want to look at "lockless malloc". It seems to be all round better, because TCMalloc requires a very specific additional library (libunwind-0.99-beta) and has got problems with glibc and locking, too. "lockless malloc" is free of locking, very small, available as GPLv3 open source and said be be faster than TCMalloc. See here: http://locklessinc.com/benchmarks_allocator.shtml
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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 be the default > if you have recent enough binutils. > > Richard I have been trying to get around this oddity by creating a statically linked compiler, but I keep running into the same problem. Is the building of a statically linked gcc (with lto and linker plugin enabled) actually supported? I keep using --with-boot-ldflags="... -static -fuse-linker-plugin", but get the message: "xgcc: error: -fuse-linker-plugin is not supported in this configuration" This happens while make is configuring for stage 3: ... rm -f stage_current make[3]: Leaving directory '/var/tmp/build-pkg-32413/obj/gcc-4.9-lto-plugin' make[2]: Leaving directory '/var/tmp/build-pkg-32413/obj/gcc-4.9-lto-plugin' make[2]: Entering directory '/var/tmp/build-pkg-32413/obj/gcc-4.9-lto-plugin' Configuring stage 3 in ./lto-plugin Configuring stage 3 in ./zlib Configuring stage 3 in ./intl Configuring stage 3 in ./libdecnumber Configuring stage 3 in ./libiberty Configuring stage 3 in ./libbacktrace ... $ more libbacktrace/config.log ... configure:2936: checking for C compiler default output file name configure:2958: /var/tmp/build-pkg-32413/obj/gcc-4.9-lto-plugin/./prev-gcc/xgcc -B/var/tmp/build-pkg-32413/obj/gcc-4.9-lto-plugin/./prev-gcc/ -B/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/bin/ -B/home /sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/bin/ -B/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/lib/ -isystem /home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/include -isystem /home/sven/gcc-lto-plu gin/x86_64-unknown-linux-gnu/sys-include-g -O2 -flto=jobserver -frandom-seed=1 -ffat-lto-objects -static -flto=1 -flto-partition=none -fuse-linker-plugin conftest.c >&5 xgcc: error: -fuse-linker-plugin is not supported in this configuration ... It can be seen for all the directories that are being configured for stage 3. Without "-fuse-linker-plugin" does it create a compiler and it also works for a non-static build.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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-plugin-flags="-pipe -O2 -march=native -fomit-frame-pointer -fno-builtin-memcmp" to avoid the "-static" option from being passed onto the plugin, but it fails. During stage1 does it still work and builds liblto_plugin.so as follows: ... /bin/bash ./libtool --tag=CC --tag=disable-static --mode=compile gcc -DHAVE_CONFIG_H -I. -I/var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin lto-plugin -I/var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin ../include -DHAVE_CONFIG_H -Wall -g -c -o lto-plugin.lo /var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin/lto-plugin.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I/var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin -I/var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin/../include -DHAVE_CONFIG_H -Wall -g -c /var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin/lto-plugin.c -fPIC -DPIC -o .libs/lto-plugin.o /bin/bash ./libtool --tag=CC --tag=disable-static --mode=link gcc -Wall -g -Wc,-static-libgcc -module -bindir /home/sven/gcc-lto-plugin/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2 -static-libstdc++ -static-libgcc -pipe -O2 -march=native -fomit-frame-pointer -fno-builtin-memcmp -o liblto_plugin.la -rpath /home/sven/gcc-lto-plugin/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2 lto-plugin.lo -Wc,../libiberty/pic/libiberty.a libtool: link: gcc -shared .libs/lto-plugin.o-static-libgcc -march=native ../libiberty/pic/libiberty.a -Wl,-soname -Wl,liblto_plugin.so.0 -o .libs/liblto_plugin.so.0.0.0 libtool: link: (cd ".libs" && rm -f "liblto_plugin.so.0" && ln -s "liblto_plugin.so.0.0.0" "liblto_plugin.so.0") libtool: link: (cd ".libs" && rm -f "liblto_plugin.so" && ln -s "liblto_plugin.so.0.0.0" "liblto_plugin.so") libtool: link: ( cd ".libs" && rm -f "liblto_plugin.la" && ln -s "../liblto_plugin.la" "liblto_plugin.la" ) ... This leads to stage1 having a working plugin. For stage2 does it change: /bin/bash ./libtool --tag=CC --tag=disable-static --mode=compile /var/tmp/build-pkg-32413/obj/gcc-4.9-lto-plugin/./prev-gcc/xgcc -B/var/tmp/build-pkg-32413/obj/gcc-4.9-lto-plugin/./prev-gcc/ -B/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/bin/ -B/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/bin/ -B/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/lib/ -isystem /home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/include -isystem /home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I/var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin -I/var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin/../include -DHAVE_CONFIG_H -Wall -g -O2 -flto=jobserver -frandom-seed=1 -ffat-lto-objects -c -o lto-plugin.lo /var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin/lto-plugin.c ... This already looks wrong. Although it has removed "-static" from the options is it actually using those I have given with --with-boot-ldflags="..." and it is not using those given with --enable-linker-plugin-flags="...". It continues with: libtool: compile: /var/tmp/build-pkg-32413/obj/gcc-4.9-lto-plugin/./prev-gcc/xgcc -B/var/tmp/build-pkg-32413/obj/gcc-4.9-lto-plugin/./prev-gcc/ -B/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/bin/ -B/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/bin/ -B/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/lib/ -isystem /home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/include -isystem /home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I/var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin -I/var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin/../include -DHAVE_CONFIG_H -Wall -g -O2 -flto=jobserver -frandom-seed=1 -ffat-lto-objects -c /var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin/lto-plugin.c -fPIC -DPIC -o .libs/lto-plugin.o # (line B) /bin/bash ./libtool --tag=CC --tag=disable-static --mode=link /var/tmp/build-pkg-32413/obj/gcc-4.9-lto-plugin/./prev-gcc/xgcc -B/var/tmp/build-pkg-32413/obj/gcc-4.9-lto-plugin/./prev-gcc/ -B/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/bin/ -B/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/bin/ -B/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/lib/ -isystem /home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/include -isystem /home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/sys-include-Wall -g -O2 -flto=jobserver -frandom-seed=1 -ffat-lto-objects -Wc,-static-libgcc -module -bindir /home/sven/gcc-lto-plugin/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2 -static -flto=1 -flto-partition=none -fuse-linker-plugin -o liblto_plugin.la -rpath /home/sven/gcc-lto-plugin/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2 lto-plugin.lo -Wc,../libiberty/pic/libiberty.a libtool: link: ar rc .libs/liblto_pl
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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 exist in 4.9, but only exist with the upcoming 4.10. Someone has been fast with the web updates and now one cannot trust them for building a stable compiler *sigh*. Anyhow, it explains why I cannot bootstrap a statically linked compiler with lto and linker plugin. Will this be taken care of for 4.9.2? And can I leave this here or shall I make a new report for it?
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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 Venkataramanan > > --- > > Richard, What I understand is that instead of using tune flags for garbage > > collection, need to try and fix the object code differences? > > Yes, it points at real bugs. OTOH fixing that may not be suitable > for the release branches, neither is passing fixed values for GC > parameters. So I'm not quite sure what a suitable workaround is > (well, make sure !defined ENABLE_GC_CHECKING && !defined > ENABLE_GC_ALWAYS_COLLECT is consistent between stage1 and stage2 > for bootstrap-lto, that is, init_ggc_heuristics () is executed > in the same way) Hi richard, In Stage1 we add --enable-checking=yes,types and it sets ENABLE_GC_CHECKING as true In Stage2 for release branches it sets ENABLE_GC_CHECKING as false. So the check "#if !defined ENABLE_GC_CHECKING && !defined ENABLE_GC_ALWAYS_COLLECT" will be true for stage2 only. ENABLE_GC_ALWAYS_COLLECT is false in both stages. Do we need to make sure stage 1 and stage 2 executes the function init_ggc_heuristics and will it set the parameters to same value?
[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 #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 Venkataramanan > > > --- > > > Richard, What I understand is that instead of using tune flags for garbage > > > collection, need to try and fix the object code differences? > > > > Yes, it points at real bugs. OTOH fixing that may not be suitable > > for the release branches, neither is passing fixed values for GC > > parameters. So I'm not quite sure what a suitable workaround is > > (well, make sure !defined ENABLE_GC_CHECKING && !defined > > ENABLE_GC_ALWAYS_COLLECT is consistent between stage1 and stage2 > > for bootstrap-lto, that is, init_ggc_heuristics () is executed > > in the same way) > > Hi richard, > > In Stage1 we add --enable-checking=yes,types and it sets ENABLE_GC_CHECKING > as > true > > In Stage2 for release branches it sets ENABLE_GC_CHECKING as false. So the > check "#if !defined ENABLE_GC_CHECKING && !defined ENABLE_GC_ALWAYS_COLLECT" > will be true for stage2 only. > > ENABLE_GC_ALWAYS_COLLECT is false in both stages. > > Do we need to make sure stage 1 and stage 2 executes the function > init_ggc_heuristics and will it set the parameters to same value? Well, it would be a workaround only. The real fix is to track down and fix all remaining issues we have with regarding to IL differences caused by collection changes. First one is fixed, 2nd one is not yet tracked down completely (feel free to continue - it takes a lot of time and I have other stuff to do right now)
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 --- Comment #53 from Venkataramanan --- Hi Richard, >> Well, it would be a workaround only. The real fix is to track down and fix >> all remaining issues we have with regarding to IL differences caused by >> collection changes. In your earlier comment you mentioned that > OTOH fixing that may not be suitable > for the release branches, neither is passing fixed values for GC > parameters. So for release branch 4.9 shall we go for this workaround patch ? > First one is fixed, 2nd one is not yet tracked down completely (feel free to > continue - it takes a lot of time and I have other stuff to do right now) I am new to LTO but would love to work learn and contribute :) Thanks Venkat. -Original Message- From: rguenther at suse dot de [mailto:gcc-bugzi...@gcc.gnu.org] Sent: Monday, 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 #51 from Venkataramanan com> --- (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 Venkataramanan > > dot com> --- Richard, What I understand is that instead of using > > > tune flags for garbage collection, need to try and fix the object code > > > differences? > > > > Yes, it points at real bugs. OTOH fixing that may not be suitable > > for the release branches, neither is passing fixed values for GC > > parameters. So I'm not quite sure what a suitable workaround is > > (well, make sure !defined ENABLE_GC_CHECKING && !defined > > ENABLE_GC_ALWAYS_COLLECT is consistent between stage1 and stage2 for > > bootstrap-lto, that is, init_ggc_heuristics () is executed in the > > same way) > > Hi richard, > > In Stage1 we add --enable-checking=yes,types and it sets > ENABLE_GC_CHECKING as true > > In Stage2 for release branches it sets ENABLE_GC_CHECKING as false. So > the check "#if !defined ENABLE_GC_CHECKING && !defined > ENABLE_GC_ALWAYS_COLLECT" > will be true for stage2 only. > > ENABLE_GC_ALWAYS_COLLECT is false in both stages. > > Do we need to make sure stage 1 and stage 2 executes the function > init_ggc_heuristics and will it set the parameters to same value? Well, it would be a workaround only. The real fix is to track down and fix all remaining issues we have with regarding to IL differences caused by collection changes. First one is fixed, 2nd one is not yet tracked down completely (feel free to continue - it takes a lot of time and I have other stuff to do right now) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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 would be a workaround only. The real fix is to track down and > >> fix all remaining issues we have with regarding to IL differences caused > >> by collection changes. > > In your earlier comment you mentioned that > > > OTOH fixing that may not be suitable > > for the release branches, neither is passing fixed values for GC > > parameters. > > So for release branch 4.9 shall we go for this workaround patch ? 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.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 --- Comment #55 from Venkataramanan --- Hi Richard, >> 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. Linaro releases are based GCC 4.9 and 4.8 branches and so we wanted to release GCC 4.9 compiler that would bootstrap LTO. So once we fix things in gcc 5.0, we will be back porting to 4.9 /4.8 branches ? Or we need to tell users that GCC 4.9 or GCC 4.8 will always need workarounds 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=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 com> --- Hi Richard, > > >> Well, it would be a workaround only. The real fix is to track down and > >> fix all remaining issues we have with regarding to IL differences caused > >> by collection changes. > > In your earlier comment you mentioned that > > > OTOH fixing that may not be suitable for the release branches, > > neither is passing fixed values for GC parameters. > > So for release branch 4.9 shall we go for this workaround patch ? 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. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
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 working in any of the recent stable compilers. 5.0 is not stable yet and said to be release not before next year. At least one of the stable compilers should be able to bootstrap itself with LTO, because it is one of the primary features in its latest development. It just looks bad when it fails and will discourage people from adopting it. You do want GCC users to make use of all its features. Why else put them in there in the first place, or just make them wait, when it is easy to fix?
