[Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails,

[Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails,

[sven.c.dack at virginmedia dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077

            Bug ID: 62077
           Summary: --with-build-config=bootstrap-lto fails,
           Product: gcc
           Version: lto
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sven.c.dack at virginmedia dot com

Hello,

I am having a problem bootstrapping GCC with LTO enabled. This used to work
fine for 4.7, but has been failing for me with 4.8 and 4.9. It reports
comparision errors between stage 2 and stage 3. I have not had a single success
getting this to work past 4.7, but also have not found any clues in the bug
database or simply googling for similar reports of this kind.

The standard bootstrap and the profiled bootstrap are working correctly.

I have disected some of the reported files including cc1 to see where exactly
the differences occur.

I do not believe there is a serious bug here, but that it has got to do with
how LTO packs its data into the object files from one stage to the next,
which is causing the comparison of stage 2 and 3 to fail.

The resulting cc1's between stage2 and stage3 show no difference when
disassembled.

Sven

...

$ configure --prefix="/home/sven/gnu" --with-gmp="/home/sven/gnu"
--with-mpfr="/home/sven/gnu" --with-mpc="/home/sven/gnu" --with-arch=native
--enable-multiarch --enable-lto --enable-stage1-languages=c,lto
--enable-stage1-checking --enable-languages=c,c++,lto
--with-build-config=bootstrap-lto
...
$ make -j8 bootstrap
...
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
gcc/dwarf2out.o differs
gcc/tree-ssa-loop-ivcanon.o differs
gcc/sel-sched-ir.o differs
gcc/regcprop.o differs
gcc/emit-rtl.o differs
gcc/cfgloopmanip.o differs
gcc/tree-diagnostic.o differs
gcc/cfgloop.o differs
gcc/tree-inline.o differs
gcc/function.o differs
gcc/tree-ssa-uninit.o differs
gcc/dwarf2cfi.o differs
gcc/c/c-parser.o differs
gcc/c/c-typeck.o differs
gcc/tree-vrp.o differs
gcc/tree.o differs
gcc/c-family/c-pragma.o differs
gcc/c-family/c-ada-spec.o differs
gcc/cfgexpand.o differs
gcc/tree-ssa-pre.o differs
gcc/ipa-devirt.o differs
gcc/cgraphunit.o differs
gcc/tree-eh.o differs
gcc/omp-low.o differs
gcc/ipa-inline-analysis.o differs
gcc/tree-outof-ssa.o differs
gcc/lto-cgraph.o differs
gcc/lto-streamer-out.o differs
gcc/cp/cp-gimplify.o differs
gcc/cp/pt.o differs
gcc/cp/name-lookup.o differs
gcc/cp/class.o differs
gcc/cp/semantics.o differs
gcc/cp/parser.o differs
gcc/cfgrtl.o differs
gcc/tree-cfg.o differs
gcc/gimple.o differs
gcc/dbxout.o differs
gcc/except.o differs
gcc/reload1.o differs
gcc/coverage.o differs
gcc/tree-sra.o differs
gcc/i386.o differs
gcc/sel-sched.o differs
gcc/tree-switch-conversion.o differs
gcc/tree-ssa-operands.o differs
gcc/varasm.o differs
gcc/gimple-low.o differs
gcc/tree-ssa-propagate.o differs
gcc/build/genconfig.o differs
gcc/build/genpeep.o differs
libcpp/directives.o differs
libcpp/lex.o differs
libcpp/macro.o differs
Makefile:19836: recipe for target 'compare' failed
$
#
# No significant difference in config.log between stage 2 and 3
# other than the names of temporary files:
#
$ diff stage[23]-gcc/config.log
2314c2314
< /tmp/cc1wn6ag.ltrans0.ltrans.o: In function `main':
---
> /tmp/ccVbm6x9.ltrans0.ltrans.o: In function `main':
2752c2752
< /tmp/ccdtyquJ.ltrans0.ltrans.o: In function `main':
---
> /tmp/cc66S1GF.ltrans0.ltrans.o: In function `main':
2929c2929
< /tmp/ccgTPlF5.ltrans0.ltrans.o: In function `main':
---
> /tmp/ccshOvII.ltrans0.ltrans.o: In function `main':
3141c3141
< /tmp/cc0Osz71.ltrans0.ltrans.o: In function `main':
---
> /tmp/cc5a2nc2.ltrans0.ltrans.o: In function `main':
3328c3328
< /tmp/ccCMoCjR.ltrans0.ltrans.o: In function `main':
---
> /tmp/ccDwogIJ.ltrans0.ltrans.o: In function `main':
4133c4133
< /tmp/ccJSSHN0.ltrans0.ltrans.o: In function `main':
---
> /tmp/ccNPnSni.ltrans0.ltrans.o: In function `main':
6037c6037
< /tmp/ccQprl5u.ltrans0.ltrans.o: In function `main':
---
> /tmp/ccCyPfzP.ltrans0.ltrans.o: In function `main':

#
# Disection of cc1-checksum.o:
#
$ du -b stage[23]-gcc/cc1-checksum.o
31824    stage2-gcc/cc1-checksum.o
31824    stage3-gcc/cc1-checksum.o
$ (cd stage2-gcc;objdump -x cc1-checksum.o) >s2od
$ (cd stage3-gcc;objdump -x cc1-checksum.o) >s3od
$ diff s[23]od
26c26
<   8 .gnu.lto_.decls.0 000002eb  0000000000000000  0000000000000000  00000093 
2**0
---
>   8 .gnu.lto_.decls.0 000002e8  0000000000000000  0000000000000000  00000093  2**0
28c28
<   9 .gnu.lto_.symtab.0 00000023  0000000000000000  0000000000000000  0000037e
 2**0
---
>   9 .gnu.lto_.symtab.0 00000023  0000000000000000  0000000000000000  0000037b  2**0
30c30
<  10 .gnu.lto_.opts 000002a4  0000000000000000  0000000000000000  000003a1 
2**0
---
>  10 .gnu.lto_.opts 000002a4  0000000000000000  0000000000000000  0000039e  2**0
#
# Large difference in section .gnu.lto_.decls.0 of cc1-checksum.o:
#
$ objcopy stage2-gcc/cc1-checksum.o --dump-section
.gnu.lto_.decls.0=s2_lto_decls0
$ objcopy stage3-gcc/cc1-checksum.o --dump-section
.gnu.lto_.decls.0=s3_lto_decls0
$ cmp s[23]_lto_decls0
s2_lto_decls0 s3_lto_decls0 differ: byte 5, line 1
$ od -x s2_lto_decls0 | head -5
0000000 9c78 937d 485d 5193 c718 67df ceaf f87d
0000020 0651 c312 958b 8524 745a dd91 0444 645d
0000040 5d37 75d5 1ae8 d929 d22e 9745 0367 6269
0000060 94ea d334 99b0 ab9a 9afc cda9 35f9 cd35
0000100 56cf 5b53 9069 a228 d094 9686 191f 39eb
$ od -x s3_lto_decls0 | head -5
0000000 9c78 937d 4c4b 5153 8610 f4ef 2942 296d
0000020 898a 0d31 268b 0424 6803 c85c 18ca 1713
0000040 72ba 6b25 b503 1411 0059 5c4d 9a1e 1490
0000060 2c51 1e44 4af2 452b 3c88 a3cb f2d6 3cb0
0000100 40ac 55e5 1a0a 8a31 8210 0c01 a025 2128
#
# Small difference in section .gnu.lto_.symtab.0 of cc1-checksum.o:
#
$ objcopy stage2-gcc/cc1-checksum.o --dump-section
.gnu.lto_.symtab.0=s2_lto_symtab0
$ objcopy stage3-gcc/cc1-checksum.o --dump-section
.gnu.lto_.symtab.0=s3_lto_symtab0
$ cmp s[23]_lto_symtab0
s2_lto_symtab0 s3_lto_symtab0 differ: byte 32, line 1
$ od -x s2_lto_symtab0
0000000 7865 6365 7475 6261 656c 635f 6568 6b63
0000020 7573 006d 0000 0000 0000 0000 0000 d700
0000040 0000 0000                          ^^
0000043
$ od -x s3_lto_symtab0
0000000 7865 6365 7475 6261 656c 635f 6568 6b63
0000020 7573 006d 0000 0000 0000 0000 0000 d600
0000040 0000 0000                          ^^
0000043
#
# No (or invisible) difference in section .gnu.lto_.opts of cc1-checksum.o:
#
$ objcopy stage2-gcc/cc1-checksum.o --dump-section .gnu.lto_.opts=s2_lto_opts
$ objcopy stage3-gcc/cc1-checksum.o --dump-section .gnu.lto_.opts=s3_lto_opts
$ du -b s[23]_lto_opts
676    s2_lto_opts
676    s3_lto_opts
$ cmp s[23]_lto_opts
$ cat s2_lto_opts
'-fno-trapv' '-march=amdfam10' '-mmmx' '-m3dnow' '-msse' '-msse2' '-msse3'
'-mno-ssse3' '-msse4a' '-mcx16' '-msahf' '-mno-movbe' '-mno-aes' '-mno-sha'
'-mno-pclmul' '-mpopcnt' '-mabm' '-mno-lwp' '-mno-fma' '-mno-fma4' '-mno-xop'
'-mno-bmi' '-mno-bmi2' '-mno-tbm' '-mno-avx' '-mno-avx2' '-mno-sse4.2'
'-mno-sse4.1' '-mlzcnt' '-mno-rtm' '-mno-hle' '-mno-rdrnd' '-mno-f16c'
'-mno-fsgsbase' '-mno-rdseed' '-mprfchw' '-mno-adx' '-mfxsr' '-mno-xsave'
'-mno-xsaveopt' '-mno-avx512f' '-mno-avx512er' '-mno-avx512cd' '-mno-avx512pf'
'-mno-prefetchwt1' '-mtune=generic' '-g' '-O2' '-flto=jobserver'
'-frandom-seed=1' '-ffat-lto-objects' '-fno-exceptions'
'-fasynchronous-unwind-tables'
$ cat s3_lto_opts
'-fno-trapv' '-march=amdfam10' '-mmmx' '-m3dnow' '-msse' '-msse2' '-msse3'
'-mno-ssse3' '-msse4a' '-mcx16' '-msahf' '-mno-movbe' '-mno-aes' '-mno-sha'
'-mno-pclmul' '-mpopcnt' '-mabm' '-mno-lwp' '-mno-fma' '-mno-fma4' '-mno-xop'
'-mno-bmi' '-mno-bmi2' '-mno-tbm' '-mno-avx' '-mno-avx2' '-mno-sse4.2'
'-mno-sse4.1' '-mlzcnt' '-mno-rtm' '-mno-hle' '-mno-rdrnd' '-mno-f16c'
'-mno-fsgsbase' '-mno-rdseed' '-mprfchw' '-mno-adx' '-mfxsr' '-mno-xsave'
'-mno-xsaveopt' '-mno-avx512f' '-mno-avx512er' '-mno-avx512cd' '-mno-avx512pf'
'-mno-prefetchwt1' '-mtune=generic' '-g' '-O2' '-flto=jobserver'
'-frandom-seed=1' '-ffat-lto-objects' '-fno-exceptions'
'-fasynchronous-unwind-tables'
#
# Large difference in section .rodata of cc1-checksum.o:
#
$ objcopy stage2-gcc/cc1-checksum.o --dump-section .rodata=s2_rodata
$ objcopy stage3-gcc/cc1-checksum.o --dump-section .rodata=s3_rodata
$ cmp s[23]_rodata
s2_rodata s3_rodata differ: byte 1, line 1
$ od -x s2_rodata
0000000 4849 6e81 e223 c9fc 8b37 210f 769a c061
0000020
$ od -x s3_rodata
0000000 68e3 9eb6 ae6a a572 9e55 94fa c6d4 b5a0
0000020
#
# Stage 2 & 3 compiler invocation of cc1-checksum.o have been identical.
# Stage 2:
#
/var/tmp/build-pkg-19462/obj/gcc-4.9-20140806/./prev-gcc/xg++
-B/var/tmp/build-pkg-19462/obj/gcc-4.9-20140806/./prev-gcc/
-B/home/sven/gnu/x86_64-unknown-linux-gnu/bin/ -nostdinc++
-B/var/tmp/build-pkg-19462/obj/gcc-4.9-20140806/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/var/tmp/build-pkg-19462/obj/gcc-4.9-20140806/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/var/tmp/build-pkg-19462/obj/gcc-4.9-20140806/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu

-I/var/tmp/build-pkg-19462/obj/gcc-4.9-20140806/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include
 -I/var/tmp/build-pkg-19462/src/gcc-4.9-20140806/libstdc++-v3/libsupc++
-L/var/tmp/build-pkg-19462/obj/gcc-4.9-20140806/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/var/tmp/build-pkg-19462/obj/gcc-4.9-20140806/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-c  -DIN_GCC_FRONTEND -g -O2 -flto=jobserver -frandom-seed=1 -ffat-lto-objects
-DIN_GCC    -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H
-I. -I. -I/var/tmp/build-pkg-19462/src/gcc-4.9-20140806/gcc
-I/var/tmp/build-pkg-19462/src/gcc-4.9-20140806/gcc/.
-I/var/tmp/build-pkg-19462/src/gcc-4.9-20140806/gcc/../include
-I/var/tmp/build-pkg-19462/src/gcc-4.9-20140806/gcc/../libcpp/include
-I/home/sven/gnu/include -I/home/sven/gnu/include -I/home/sven/gnu/include 
-I/var/tmp/build-pkg-19462/src/gcc-4.9-20140806/gcc/../libdecnumber
-I/var/tmp/build-pkg-19462/src/gcc-4.9-20140806/gcc/../libdecnumber/bid
-I../libdecnumber
-I/var/tmp/build-pkg-19462/src/gcc-4.9-20140806/gcc/../libbacktrace  
-I/home/sven/gnu/include -o cc1-checksum.o -MT cc1-checksum.o -MMD -MP -MF
./.deps/cc1-checksum.TPo cc1-checksum.c
#
# Stage 3:
#
/var/tmp/build-pkg-19462/obj/gcc-4.9-20140806/./prev-gcc/xg++
-B/var/tmp/build-pkg-19462/obj/gcc-4.9-20140806/./prev-gcc/
-B/home/sven/gnu/x86_64-unknown-linux-gnu/bin/ -nostdinc++
-B/var/tmp/build-pkg-19462/obj/gcc-4.9-20140806/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/var/tmp/build-pkg-19462/obj/gcc-4.9-20140806/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/var/tmp/build-pkg-19462/obj/gcc-4.9-20140806/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu

-I/var/tmp/build-pkg-19462/obj/gcc-4.9-20140806/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include
 -I/var/tmp/build-pkg-19462/src/gcc-4.9-20140806/libstdc++-v3/libsupc++
-L/var/tmp/build-pkg-19462/obj/gcc-4.9-20140806/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/var/tmp/build-pkg-19462/obj/gcc-4.9-20140806/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-c  -DIN_GCC_FRONTEND -g -O2 -flto=jobserver -frandom-seed=1 -ffat-lto-objects
-DIN_GCC    -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H
-I. -I. -I/var/tmp/build-pkg-19462/src/gcc-4.9-20140806/gcc
-I/var/tmp/build-pkg-19462/src/gcc-4.9-20140806/gcc/.
-I/var/tmp/build-pkg-19462/src/gcc-4.9-20140806/gcc/../include
-I/var/tmp/build-pkg-19462/src/gcc-4.9-20140806/gcc/../libcpp/include
-I/home/sven/gnu/include -I/home/sven/gnu/include -I/home/sven/gnu/include 
-I/var/tmp/build-pkg-19462/src/gcc-4.9-20140806/gcc/../libdecnumber
-I/var/tmp/build-pkg-19462/src/gcc-4.9-20140806/gcc/../libdecnumber/bid
-I../libdecnumber
-I/var/tmp/build-pkg-19462/src/gcc-4.9-20140806/gcc/../libbacktrace  
-I/home/sven/gnu/include -o cc1-checksum.o -MT cc1-checksum.o -MMD -MP -MF
./.deps/cc1-checksum.TPo cc1-checksum.c

#
# Disection of i386.o:
#
$ mkdir S2 S3
$ for s in $(objdump -h stage2-gcc/i386.o|sed -n '/^[ 0-9]*[0-9] .*/{s/^[
0-9]*[0-9] \([^ ]*\) .*$/\1/;p}'|sort -u); do objcopy stage2-gcc/i386.o
--dump-section "$s"="S2/oc$s"; done
objcopy:stage2-gcc/i386.o[.bss]: can't dump section - it has no contents: File
in wrong format
objcopy:stage2-gcc/i386.o[.note.GNU-stack]: can't dump section - it is empty:
File in wrong format
objcopy:stage2-gcc/i386.o[.text.unlikely._ZN12rtl_opt_passD0Ev]: can't dump
section - it is empty: File in wrong format
objcopy:stage2-gcc/i386.o[.text.unlikely._ZN12rtl_opt_passD2Ev]: can't dump
section - it is empty: File in wrong format
$ for s in $(objdump -h stage3-gcc/i386.o|sed -n '/^[ 0-9]*[0-9] .*/{s/^[
0-9]*[0-9] \([^ ]*\) .*$/\1/;p}'|sort -u); do objcopy stage3-gcc/i386.o
--dump-section "$s"="S3/oc$s"; done
objcopy:stage3-gcc/i386.o[.bss]: can't dump section - it has no contents: File
in wrong format
objcopy:stage3-gcc/i386.o[.note.GNU-stack]: can't dump section - it is empty:
File in wrong format
objcopy:stage3-gcc/i386.o[.text.unlikely._ZN12rtl_opt_passD0Ev]: can't dump
section - it is empty: File in wrong format
objcopy:stage3-gcc/i386.o[.text.unlikely._ZN12rtl_opt_passD2Ev]: can't dump
section - it is empty: File in wrong format
$ diff S2 S3
Binary files S2/oc.gnu.lto_.decls.0 and S3/oc.gnu.lto_.decls.0 differ
Binary files S2/oc.gnu.lto_.symtab.0 and S3/oc.gnu.lto_.symtab.0 differ
$ du -b S[23]/oc.gnu.lto_.decls.0
839593 S2/oc.gnu.lto_.decls.0
839660 S3/oc.gnu.lto_.decls.0
$ du -b S[23]/oc.gnu.lto_.symtab.0
 61815 S2/oc.gnu.lto_.symtab.0
 61815 S3/oc.gnu.lto_.symtab.0
#
# Large difference in section .gnu.lto_.decls.0 of i386.o:
#
$ od -x S2/oc.gnu.lto_.decls.0|head -5
0000000 9c78 bde4 b809 558e fffb db7d 291b 84a4
0000020 1106 aa65 0d14 941a 8506 ce6d 40d0 24a4
0000040 94b3 9527 4734 2683 4a92 f69e 77be 541a
0000060 ec22 0d2d cd0a 3e34 8f29 3e32 939a 2a26
0000100 db7b 3f7a 6b5f 5d9d beeb b5f6 f9e5 fefd
$ od -x S3/oc.gnu.lto_.decls.0|head -5
0000000 9c78 bde4 b809 558e fffb b37d 8525 4328
0000020 1483 3632 1a51 1295 a361 d0c8 5d80 424a
0000040 1ec6 9a8d 9a07 2a53 7a95 7dec 94ef 9126
0000060 96cd 4506 d273 3cac e532 3cd1 a250 37b2
0000100 f79e ddf3 9d6b eb5d eebe cb6b fbf3 fffd
#
# Large difference in section .gnu.lto_.symtab.0 of i386,
# showing a repetitive pattern:
#
#   A constant difference of '-2' between 113 individual bytes.
#
$ od -v -w1 -t u1 S2/oc.gnu.lto_.symtab.0 >s2od
$ od -v -w1 -t u1 S3/oc.gnu.lto_.symtab.0 >s3od
$ sdiff -w 27 -s s[23]od|head -5
0000435 116  |    0000435 114
0000477 123  |    0000477 121
0000626 184  |    0000626 182
0000663   8  |    0000663   6
0000714 199  |    0000714 197
$ sdiff -w 27 -s s[23]od|wc -l
113
$ sdiff -w 27 -s s[23]od|gawk '{print $5-$2}'|sort -u
-2
#
# Stage 2 & 3 compiler invocation of i386.o have been identical.
# Stage 2:
#
/var/tmp/build-pkg-19462/obj/gcc-4.9-20140806/./prev-gcc/xg++
-B/var/tmp/build-pkg-19462/obj/gcc-4.9-20140806/./prev-gcc/
-B/home/sven/gnu/x86_64-unknown-linux-gnu/bin/ -nostdinc++
-B/var/tmp/build-pkg-19462/obj/gcc-4.9-20140806/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/var/tmp/build-pkg-19462/obj/gcc-4.9-20140806/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/var/tmp/build-pkg-19462/obj/gcc-4.9-20140806/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu

-I/var/tmp/build-pkg-19462/obj/gcc-4.9-20140806/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include
 -I/var/tmp/build-pkg-19462/src/gcc-4.9-20140806/libstdc++-v3/libsupc++
-L/var/tmp/build-pkg-19462/obj/gcc-4.9-20140806/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/var/tmp/build-pkg-19462/obj/gcc-4.9-20140806/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-c   -g -O2 -flto=jobserver -frandom-seed=1 -ffat-lto-objects -DIN_GCC   
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I.
-I/var/tmp/build-pkg-19462/src/gcc-4.9-20140806/gcc
-I/var/tmp/build-pkg-19462/src/gcc-4.9-20140806/gcc/.
-I/var/tmp/build-pkg-19462/src/gcc-4.9-20140806/gcc/../include
-I/var/tmp/build-pkg-19462/src/gcc-4.9-20140806/gcc/../libcpp/include
-I/home/sven/gnu/include -I/home/sven/gnu/include -I/home/sven/gnu/include 
-I/var/tmp/build-pkg-19462/src/gcc-4.9-20140806/gcc/../libdecnumber
-I/var/tmp/build-pkg-19462/src/gcc-4.9-20140806/gcc/../libdecnumber/bid
-I../libdecnumber
-I/var/tmp/build-pkg-19462/src/gcc-4.9-20140806/gcc/../libbacktrace  
-I/home/sven/gnu/include -o i386.o -MT i386.o -MMD -MP -MF ./.deps/i386.TPo
/var/tmp/build-pkg-19462/src/gcc-4.9-20140806/gcc/config/i386/i386.c
#
# Stage 3:
#
/var/tmp/build-pkg-19462/obj/gcc-4.9-20140806/./prev-gcc/xg++
-B/var/tmp/build-pkg-19462/obj/gcc-4.9-20140806/./prev-gcc/
-B/home/sven/gnu/x86_64-unknown-linux-gnu/bin/ -nostdinc++
-B/var/tmp/build-pkg-19462/obj/gcc-4.9-20140806/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/var/tmp/build-pkg-19462/obj/gcc-4.9-20140806/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/var/tmp/build-pkg-19462/obj/gcc-4.9-20140806/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu

-I/var/tmp/build-pkg-19462/obj/gcc-4.9-20140806/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include
 -I/var/tmp/build-pkg-19462/src/gcc-4.9-20140806/libstdc++-v3/libsupc++
-L/var/tmp/build-pkg-19462/obj/gcc-4.9-20140806/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/var/tmp/build-pkg-19462/obj/gcc-4.9-20140806/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-c   -g -O2 -flto=jobserver -frandom-seed=1 -ffat-lto-objects -DIN_GCC   
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I.
-I/var/tmp/build-pkg-19462/src/gcc-4.9-20140806/gcc
-I/var/tmp/build-pkg-19462/src/gcc-4.9-20140806/gcc/.
-I/var/tmp/build-pkg-19462/src/gcc-4.9-20140806/gcc/../include
-I/var/tmp/build-pkg-19462/src/gcc-4.9-20140806/gcc/../libcpp/include
-I/home/sven/gnu/include -I/home/sven/gnu/include -I/home/sven/gnu/include 
-I/var/tmp/build-pkg-19462/src/gcc-4.9-20140806/gcc/../libdecnumber
-I/var/tmp/build-pkg-19462/src/gcc-4.9-20140806/gcc/../libdecnumber/bid
-I../libdecnumber
-I/var/tmp/build-pkg-19462/src/gcc-4.9-20140806/gcc/../libbacktrace  
-I/home/sven/gnu/include -o i386.o -MT i386.o -MMD -MP -MF ./.deps/i386.TPo
/var/tmp/build-pkg-19462/src/gcc-4.9-20140806/gcc/config/i386/i386.c

#
# Disection of cc1:
#

$ for s in $(objdump -h stage2-gcc/cc1|sed -n '/^[ 0-9]*[0-9] .*/{s/^[
0-9]*[0-9] \([^ ]*\) .*$/\1/;p}'|sort -u); do objcopy stage2-gcc/cc1
--dump-section "$s"="S2/oc$s"; done
objcopy:stage2-gcc/cc1[.bss]: can't dump section - it has no contents: File in
wrong format
objcopy:stage2-gcc/cc1[.tbss]: can't dump section - it has no contents: File in
wrong format
$ for s in $(objdump -h stage3-gcc/cc1|sed -n '/^[ 0-9]*[0-9] .*/{s/^[
0-9]*[0-9] \([^ ]*\) .*$/\1/;p}'|sort -u); do objcopy stage3-gcc/cc1
--dump-section "$s"="S3/oc$s"; done
objcopy:stage3-gcc/cc1[.bss]: can't dump section - it has no contents: File in
wrong format
objcopy:stage3-gcc/cc1[.tbss]: can't dump section - it has no contents: File in
wrong format
$ diff S2 S3
Binary files S2/oc.debug_info and S3/oc.debug_info differ
Binary files S2/oc.debug_str and S3/oc.debug_str differ
Binary files S2/oc.rodata and S3/oc.rodata differ
#
# Small (~3%) difference in section .debug_info of cc1:
#
$ du -b S[23]/oc.debug_info 
27080517    S2/oc.debug_info
27080517    S3/oc.debug_info
$ od -v -w1 -t u1 S2/oc.debug_info >s2od_dbginf
$ od -v -w1 -t u1 S3/oc.debug_info >s3od_dbginf
$ sdiff -s s[23]od_dbginf|wc -l
803317
#
# Large (~54%) difference in section .debug_str of cc1.
# The section seems to be composed of only text strings,
# of which many are identical, but have got a
# difference in their sorting order. The text strings
# that are truly different are the names of the
# temporary files.
#
$ du -b S[23]/oc.debug_str
1959617    S2/oc.debug_str
1959617    S3/oc.debug_str
$ od -v -w1 -t u1 S2/oc.debug_str >s2od_dbgstr
$ od -v -w1 -t u1 S3/oc.debug_str >s3od_dbgstr
$ sdiff -s s[23]od_dbgstr|wc -l
1050232
$ strings S2/oc.debug_str >s2strings_dbgstr
$ strings S3/oc.debug_str >s3strings_dbgstr
$ wc s[23]strings_dbgstr
  97147   97334 1959617 s2strings_dbgstr
  97147   97334 1959617 s3strings_dbgstr
194294  194668 3919234 total
$ sdiff -s s[23]strings_dbgstr|wc -l
84
$ sort s2strings_dbgstr >s2strings_dbgstr_sorted
$ sort s3strings_dbgstr >s3strings_dbgstr_sorted
$ sdiff -s s[23]strings_dbgstr_sorted|wc -l
31
$ sdiff -s s[23]strings_dbgstr_sorted|head -5
/tmp/ccWGjBRg.ltrans0.o                          |    /tmp/ccpAN020.ltrans0.o
/tmp/ccWGjBRg.ltrans10.o                      |    /tmp/ccpAN020.ltrans10.o
/tmp/ccWGjBRg.ltrans11.o                      |    /tmp/ccpAN020.ltrans11.o
/tmp/ccWGjBRg.ltrans12.o                      |    /tmp/ccpAN020.ltrans12.o
/tmp/ccWGjBRg.ltrans13.o                      |    /tmp/ccpAN020.ltrans13.o
#
# Small difference in section .rodata of cc1:
#
$ od -v -w8 -t x8 S2/oc.rodata >s2od
$ od -v -w8 -t x8 S3/oc.rodata >s3od
$ sdiff -w 57 -s s[23]od
15541720 c9fce2236e814849   |    15541720 a572ae6a9eb668e3
15541730 c061769a210f8b37   |    15541730 b5a0c6d494fa9e55
#
# Disassembly of cc1:
# - no difference found -
#
$ objdump -d stage2-gcc/cc1 | tail -n +3 >s2od_cc1_dis
$ objdump -d stage3-gcc/cc1 | tail -n +3 >s3od_cc1_dis
$ wc -l s[23]od_cc1_dis
  2325343 s2od_cc1_dis
  2325343 s3od_cc1_dis
  4650686 total
$ diff -s s[23]od_cc1_dis
Files s2od_cc1_dis and s3od_cc1_dis are identical


$ uname -a
Linux debian-linux 3.14.16-sven #1 SMP Fri Aug 8 11:50:49 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,

[sven.c.dack at virginmedia dot com]

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,

[sven.c.dack at virginmedia dot com]

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=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,

[rguenth at gcc dot gnu.org]

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,

[rguenth at gcc dot gnu.org]

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,

[venkataramanan.kumar at amd dot com]

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,

[sven.c.dack at virginmedia dot com]

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,

[sven.c.dack at virginmedia dot com]

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=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,

[pinskia at gcc dot gnu.org]

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,

[rguenther at suse dot de]

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,

[venkataramanan.kumar at amd dot com]

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_dispatch    lngt: 20      

Stage3
@103169 identifier_node  strg: debug_ready_dispatch    lngt: 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,

[rguenth at gcc dot gnu.org]

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,

[venkataramanan.kumar at amd dot com]

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,

[sven.c.dack at virginmedia dot com]

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,

[rguenth at gcc dot gnu.org]

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

4237        case 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

[sven.c.dack at virginmedia dot com]

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

[sven.c.dack at virginmedia dot com]

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=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

[rguenth at gcc dot gnu.org]

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

[rguenth at gcc dot gnu.org]

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

[venkataramanan.kumar at amd dot com]

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

[rguenth at gcc dot gnu.org]

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
 <0x7ffff5af4e70> const char[28]
#endif
 <0x7ffff5af6000> const char[7]
#define HAVE_cc0 1
 <0x7ffff5af6150> const char[19]
#define CC0_P(X) ((X) == cc0_rtx)
 <0x7ffff5af62a0> const char[34]
#define CC0_P(X) ((X) ? 0 : 0)
 <0x7ffff5aef540> const char[31] <0x7ffff5aef498> char[31]
#define HAVE_conditional_move 1
 <0x7ffff5aefe70> const char[32] <0x7ffff5de6d20> char[32]
#define HAVE_conditional_execution 1
 <0x7ffff5af6690> const char[37]
#define HAVE_lo_sum 1
 <0x7ffff5af67e0> const char[22]
#define HAVE_peephole 1
 <0x7ffff5af6930> const char[24]
#define HAVE_peephole2 1
 <0x7ffff5af45e8> const char[25] <0x7ffff5af4540> char[25]

and for stage3:

#ifndef MAX_INSNS_PER_SPLIT
 <0x7ffff5db9150> const char[28]
#endif
 <0x7ffff601bc78> const char[7] <0x7ffff601bbd0> char[7]
#define HAVE_cc0 1
 <0x7ffff5db93f0> const char[19]
#define CC0_P(X) ((X) == cc0_rtx)
 <0x7ffff5db9540> const char[34]
#define CC0_P(X) ((X) ? 0 : 0)
 <0x7ffff5db17e0> const char[31] <0x7ffff5db1738> char[31]
#define HAVE_conditional_move 1
 <0x7ffff5db4150> const char[32] <0x7ffff6017888> char[32]
#define HAVE_conditional_execution 1
 <0x7ffff5db9930> const char[37]
#define HAVE_lo_sum 1
 <0x7ffff5db9a80> const char[22]
#define HAVE_peephole 1
 <0x7ffff5db9bd0> const char[24]
#define HAVE_peephole2 1
 <0x7ffff5db5888> const char[25] <0x7ffff5db57e0> 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

[rguenth at gcc dot gnu.org]

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
>  <0x7ffff5af4e70> const char[28]
> #endif
>  <0x7ffff5af6000> const char[7]
> #define HAVE_cc0 1
>  <0x7ffff5af6150> const char[19]
> #define CC0_P(X) ((X) == cc0_rtx)
>  <0x7ffff5af62a0> const char[34]
> #define CC0_P(X) ((X) ? 0 : 0)
>  <0x7ffff5aef540> const char[31] <0x7ffff5aef498> char[31]
> #define HAVE_conditional_move 1
>  <0x7ffff5aefe70> const char[32] <0x7ffff5de6d20> char[32]
> #define HAVE_conditional_execution 1
>  <0x7ffff5af6690> const char[37]
> #define HAVE_lo_sum 1
>  <0x7ffff5af67e0> const char[22]
> #define HAVE_peephole 1
>  <0x7ffff5af6930> const char[24]
> #define HAVE_peephole2 1
>  <0x7ffff5af45e8> const char[25] <0x7ffff5af4540> char[25]
> 
> and for stage3:
> 
> #ifndef MAX_INSNS_PER_SPLIT
>  <0x7ffff5db9150> const char[28]
> #endif
>  <0x7ffff601bc78> const char[7] <0x7ffff601bbd0> char[7]
> #define HAVE_cc0 1
>  <0x7ffff5db93f0> const char[19]
> #define CC0_P(X) ((X) == cc0_rtx)
>  <0x7ffff5db9540> const char[34]
> #define CC0_P(X) ((X) ? 0 : 0)
>  <0x7ffff5db17e0> const char[31] <0x7ffff5db1738> char[31]
> #define HAVE_conditional_move 1
>  <0x7ffff5db4150> const char[32] <0x7ffff6017888> char[32]
> #define HAVE_conditional_execution 1
>  <0x7ffff5db9930> const char[37]
> #define HAVE_lo_sum 1
>  <0x7ffff5db9a80> const char[22]
> #define HAVE_peephole 1
>  <0x7ffff5db9bd0> const char[24]
> #define HAVE_peephole2 1
>  <0x7ffff5db5888> const char[25] <0x7ffff5db57e0> 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

[rguenth at gcc dot gnu.org]

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

[rguenth at gcc dot gnu.org]

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

[rguenth at gcc dot gnu.org]

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 are recorded in the type_hash_canon
hashtable.  Not sure how that code can trigger when we build m right
before using elt_type which is now either not complete or complete (and so is
t).

The above fixes the LTO miscompares.  Let's see if it survives LTO bootstrap.

[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails

[sven.c.dack at virginmedia dot com]

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

[venkataramanan.kumar at amd dot com]

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

[venkataramanan.kumar at amd dot com]

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

[venkataramanan.kumar at amd dot com]

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

[rguenth at gcc dot gnu.org]

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

[rguenth at gcc dot gnu.org]

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 <0x7ffff6703ac8>
[1969] = identifier_node <0x7ffff66ddf20>
[1970] = identifier_node <0x7ffff6706210>
[1971] = tree_list <0x7ffff6703af0>
[1972] = tree_list <0x7ffff6703c30>
[1973] = tree_list <0x7ffff6707488>
[1974] = tree_list <0x7ffff67861b8>
[1975] = tree_list <0x7ffff67861e0>
[1976] = tree_list <0x7ffff4dddaf0>
[1977] = tree_list <0x7ffff4dddac8>
[1978] = function_type <0x7ffff4de05e8>
[1979] = identifier_node <0x7ffff6781840>
[1980] = function_decl <0x7ffff6784d00>

while stage3

[1968] = tree_list <0x7ffff6703ac8>
[1969] = identifier_node <0x7ffff66ddf20>
[1970] = identifier_node <0x7ffff6706210>
[1971] = tree_list <0x7ffff6703af0>
[1972] = tree_list <0x7ffff6703c30>
[1973] = tree_list <0x7ffff6707488>
[1974] = tree_list <0x7ffff67861b8>
[1975] = tree_list <0x7ffff67861e0>
[1976] = function_type <0x7ffff4de05e8>
[1977] = identifier_node <0x7ffff6781840>
[1978] = function_decl <0x7ffff6784d00>

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

[venkataramanan.kumar at amd dot com]

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

[sven.c.dack at virginmedia dot com]

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

[sven.c.dack at virginmedia dot com]

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 passes        105750
# of unexpected failures    3
# of expected failures        252
# of expected passes        87886
# of unexpected failures    2
# of unexpected successes    2
# of expected failures        443
# of expected passes        9246
# of unexpected failures    6
# of expected failures        41
# of expected passes        689
# of expected passes        26
# of expected failures        3
# 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.

[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails

[sven.c.dack at virginmedia dot com]

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 failures		252
> # of expected passes		87886
> # of unexpected failures	2
> # of unexpected successes	2
> # of expected failures		443
> # of expected passes		9246
> # of unexpected failures	6
> # of expected failures		41
> # of expected passes		689
> # of expected passes		26
> # of expected failures		3
> # 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.
>From gcc-bugs-return-458526-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Aug 15 05:50:40 2014
Return-Path: <gcc-bugs-return-458526-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7990 invoked by alias); 15 Aug 2014 05:50:39 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 7946 invoked by uid 55); 15 Aug 2014 05:50:33 -0000
From: "amker at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/62032] FAIL: vsnprintf-chk.c execution,  -O2 -flto -fno-use-linker-plugin -flto-partition=none
Date: Fri, 15 Aug 2014 05:50:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: lto
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: lto
X-Bugzilla-Severity: normal
X-Bugzilla-Who: amker at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: amker at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-62032-4-bc3ByqFuN3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62032-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62032-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-08/txt/msg01023.txt.bz2
Content-length: 493

https://gcc.gnu.org/bugzilla/show_bug.cgi?idb032

--- Comment #6 from amker at gcc dot gnu.org ---
Author: amker
Date: Fri Aug 15 05:49:56 2014
New Revision: 214000

URL: https://gcc.gnu.org/viewcvs?rev!4000&root=gcc&view=rev
Log:

    Backport from mainline
    2014-08-08  Bin Cheng  <bin.cheng@arm.com>

    PR lto/62032
    * lto-lang.c (lto_init): Switch mis-matched arguments.


Modified:
    branches/gcc-4_9-branch/gcc/lto/ChangeLog
    branches/gcc-4_9-branch/gcc/lto/lto-lang.c

[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails

[sven.c.dack at virginmedia dot com]

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.86s    0.56s, 0.20%    100.00% (base)
profiled:   255.76s    0.72s, 0.28%    +10.60%
lto:        282.80s    0.16s, 0.06%     +0.02%
lto-plugin: 285.41s    0.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

[rguenther at suse dot de]

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.86s    0.56s, 0.20%    100.00% (base)
> profiled:   255.76s    0.72s, 0.28%    +10.60%
> lto:        282.80s    0.16s, 0.06%     +0.02%
> lto-plugin: 285.41s    0.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

[trippels at gcc dot gnu.org]

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.86s    0.56s, 0.20%    100.00% (base)
> profiled:   255.76s    0.72s, 0.28%    +10.60%
> lto:        282.80s    0.16s, 0.06%     +0.02%
> lto-plugin: 285.41s    0.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

[sven.c.dack at virginmedia dot com]

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.86s    0.56s, 0.20%    100.00% (base)
> > profiled:   255.76s    0.72s, 0.28%    +10.60%
> > lto:        282.80s    0.16s, 0.06%     +0.02%
> > lto-plugin: 285.41s    0.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

[trippels at gcc dot gnu.org]

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.86s    0.56s, 0.20%    100.00% (base)
> > > profiled:   255.76s    0.72s, 0.28%    +10.60%
> > > lto:        282.80s    0.16s, 0.06%     +0.02%
> > > lto-plugin: 285.41s    0.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

[jason at gcc dot gnu.org]

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=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

[sven.c.dack at virginmedia dot com]

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.86s    0.56s, 0.20%    100.00% (base)
> > > > profiled:   255.76s    0.72s, 0.28%    +10.60%
> > > > lto:        282.80s    0.16s, 0.06%     +0.02%
> > > > lto-plugin: 285.41s    0.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.13s    0.71, 0.25%    100.00% (base)
profiled:     255.29s    0.80, 0.31%    +10.52%
lto:          281.71s    0.70, 0.25%     +0.15%
profiled-lto: 251.38s    0.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

[sven.c.dack at virginmedia dot com]

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

[sven.c.dack at virginmedia dot com]

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

[sven.c.dack at virginmedia dot com]

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  .libs/lto-plugin.o
libtool: link: ranlib .libs/liblto_plugin.a
libtool: link: ( cd ".libs" && rm -f "liblto_plugin.la" && ln -s
"../liblto_plugin.la" "liblto_plugin.la" )
WARNING: liblto_plugin.la is static, not copying to .././gcc/liblto_plugin.la

Why is it not using the options given with --enable-linker-plugin-flags for the
2nd stage?

config.log for stage1 and stage2 both show that --enable-linker-plugin-flags
has been passed to configure:

$ head -7 stage1-lto-plugin/config.log 
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by LTO plugin for ld configure 0.1, which was
generated by GNU Autoconf 2.64.  Invocation command line was

  $ /var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin/configure
--cache-file=./config.cache --prefix=/home/sven/gcc-lto-plugin
--with-gmp=/home/sven/gcc-lto-plugin --with-mpfr=/home/sven/gcc-lto-plugin
--with-mpc=/home/sven/gcc-lto-plugin --enable-stage1-languages=c,lto
--enable-multiarch --with-arch=native --enable-checking=yes
--enable-stage1-checking=yes --enable-linker-build-id
--with-linker-hash-style=gnu --enable-lto --with-build-config=bootstrap-lto
--enable-link-mutex --enable-linker-plugin-flags=-pipe -O2 -march=native
-fomit-frame-pointer -fno-builtin-memcmp --with-boot-ldflags=-static -flto=1
-flto-partition=none -fuse-linker-plugin --enable-languages=c,c++,lto
--program-transform-name=s,y,y, --disable-option-checking
--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu
--target=x86_64-unknown-linux-gnu
--srcdir=/var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin
--disable-intermodule --enable-checking=yes --disable-coverage
--enable-languages=c,c++,lto --disable-build-format-warnings --enable-shared

$ head -7 prev-lto-plugin/config.log 
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by LTO plugin for ld configure 0.1, which was
generated by GNU Autoconf 2.64.  Invocation command line was

  $ /var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin/configure
--cache-file=./config.cache --prefix=/home/sven/gcc-lto-plugin
--with-gmp=/home/sven/gcc-lto-plugin --with-mpfr=/home/sven/gcc-lto-plugin
--with-mpc=/home/sven/gcc-lto-plugin --enable-stage1-languages=c,lto
--enable-multiarch --with-arch=native --enable-checking=yes
--enable-stage1-checking=yes --enable-linker-build-id
--with-linker-hash-style=gnu --enable-lto --with-build-config=bootstrap-lto
--enable-link-mutex --enable-linker-plugin-flags=-pipe -O2 -march=native
-fomit-frame-pointer -fno-builtin-memcmp --with-boot-ldflags=-static -flto=1
-flto-partition=none -fuse-linker-plugin --enable-languages=c,c++,lto
--program-transform-name=s,y,y, --disable-option-checking
--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu
--target=x86_64-unknown-linux-gnu
--srcdir=/var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin
--with-build-libsubdir=. --enable-shared

[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails

[sven.c.dack at virginmedia dot com]

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

[venkataramanan.kumar at amd dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077

--- Comment #51 from Venkataramanan <venkataramanan.kumar at amd dot com> ---
(In reply to rguenther@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

[rguenther at suse dot de]

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 rguenther@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

[venkataramanan.kumar at amd dot com]

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-bugzilla@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 rguenther@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

[rguenther at suse dot de]

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

[sven.c.dack at virginmedia dot com]

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

[rguenth at gcc dot gnu.org]

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

[vekumar at gcc dot gnu.org]

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

[rguenther at suse dot de]

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

[rguenth at gcc dot gnu.org]

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

[jakub at gcc dot gnu.org]

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.jj    2015-03-27 18:32:41.000000000 +0100
+++ configure.ac    2015-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

[rguenth at gcc dot gnu.org]

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

[jakub at gcc dot gnu.org]

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=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

[jakub at gcc dot gnu.org]

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=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

[hjl.tools at gmail dot com]

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