[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 --- 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 --- 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 #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 #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 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||hjl.tools at gmail dot com Version|lto |5.1.1 --- Comment #65 from H.J. Lu hjl.tools at gmail dot com --- 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 #62 from Richard Biener rguenth at gcc dot gnu.org --- 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
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #61 from Jakub Jelinek jakub at gcc dot gnu.org ---
(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 #63 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Fri Apr 17 17:09:20 2015 New Revision: 222187 URL: https://gcc.gnu.org/viewcvs?rev=222187root=gccview=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 jakub at gcc dot gnu.org --- Author: jakub Date: Fri Apr 17 17:10:27 2015 New Revision: 222189 URL: https://gcc.gnu.org/viewcvs?rev=222189root=gccview=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 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to fail||4.8.4, 4.9.2, 5.1.0 --- Comment #57 from Richard Biener rguenth at gcc dot gnu.org --- 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 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 rguenth at gcc dot gnu.org --- 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 --- Comment #51 from Venkataramanan venkataramanan.kumar at amd dot 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 venkataramanan.kumar at amd 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?
[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 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 venkataramanan.kumar at amd dot 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 venkataramanan.kumar at amd 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)
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 --- Comment #53 from Venkataramanan venkataramanan.kumar at amd dot 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 ? 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 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 venkataramanan.kumar at amd dot 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 venkataramanan.kumar at amd 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 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 venkataramanan.kumar at amd dot 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.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 --- Comment #55 from Venkataramanan venkataramanan.kumar at amd dot com --- 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 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 venkataramanan.kumar at amd dot 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 sven.c.dack at virginmedia dot com --- 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?
[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 sven.c.dack at virginmedia dot com --- ... 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 sven.c.dack at virginmedia dot com --- 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_plugin.a
[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 sven.c.dack at virginmedia dot com --- 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 #40 from Sven C. Dack sven.c.dack at virginmedia dot com --- 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 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 sven.c.dack at virginmedia dot com --- 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 trippels at gcc dot gnu.org --- (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 sven.c.dack at virginmedia dot com --- (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 trippels at gcc dot gnu.org --- (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 jason at gcc dot gnu.org --- Author: jason Date: Fri Aug 15 17:27:58 2014 New Revision: 214030 URL: https://gcc.gnu.org/viewcvs?rev=214030root=gccview=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 sven.c.dack at virginmedia dot com --- ... 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 sven.c.dack at virginmedia dot com --- 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 #31 from Venkataramanan venkataramanan.kumar at amd dot com --- (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 rguenth at gcc dot gnu.org --- 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 rguenth at gcc dot gnu.org --- 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 venkataramanan.kumar at amd 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?
[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 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 venkataramanan.kumar at amd 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)
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 --- Comment #36 from Andrew Pinski pinskia at gcc dot gnu.org --- (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 venkataramanan.kumar at amd 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) 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 sven.c.dack at virginmedia dot com --- ... 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 sven.c.dack at virginmedia dot com --- 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 sven.c.dack at virginmedia dot com --- (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 Sven C. Dack sven.c.dack at virginmedia dot com 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 sven.c.dack at virginmedia dot com --- 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 sven.c.dack at virginmedia dot com changed: What|Removed |Added Attachment #33299|0 |1 is obsolete|| --- Comment #18 from Sven C. Dack sven.c.dack at virginmedia dot com --- Created attachment 33310 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33310action=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 rguenth at gcc dot gnu.org --- 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 rguenth at gcc dot gnu.org --- (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 venkataramanan.kumar at amd dot com --- 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 rguenth at gcc dot gnu.org ---
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 rguenth at gcc dot gnu.org ---
(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 rguenth at gcc dot gnu.org --- 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 rguenth at gcc dot gnu.org 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 rguenth at gcc dot gnu.org --- Patch in testing.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #26 from Richard Biener rguenth at gcc dot gnu.org ---
(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
[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 sven.c.dack at virginmedia dot com --- (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 venkataramanan.kumar at amd dot com --- 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 venkataramanan.kumar at amd dot com --- 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 venkataramanan.kumar at amd dot com --- (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 #6 from Sven C. Dack sven.c.dack at virginmedia dot com --- 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 sven.c.dack at virginmedia dot com changed: What|Removed |Added Attachment #33285|0 |1 is obsolete|| --- Comment #7 from Sven C. Dack sven.c.dack at virginmedia dot com --- Created attachment 33299 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33299action=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 pinskia at gcc dot gnu.org --- (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 trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #9 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (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 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 trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #9 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (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 venkataramanan.kumar at amd dot com --- 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 rguenth at gcc dot gnu.org ---
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 rguenth at gcc dot gnu.org ---
(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 venkataramanan.kumar at amd dot com --- (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 sven.c.dack at virginmedia dot com --- (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 rguenth at gcc dot gnu.org --- 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 Richard Biener rguenth at gcc dot gnu.org 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 rguenth at gcc dot gnu.org --- 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 rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-* --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- 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 venkataramanan.kumar at amd dot com --- (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 #1 from Sven C. Dack sven.c.dack at virginmedia dot com --- 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 sven.c.dack at virginmedia dot com changed: What|Removed |Added CC||sven.c.dack at virginmedia dot com --- Comment #2 from Sven C. Dack sven.c.dack at virginmedia dot com --- Created attachment 33285 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33285action=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.
