https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77917
PeteVine changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77917
--- Comment #11 from PeteVine ---
Well, I finally managed to complete an LTO bootstrap on ARM (even leaving the
full complement of C(XX)FLAGS in place, bar -flto) but it seems using ld.bfd is
a must.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77917
--- Comment #10 from PeteVine ---
Yeah, I began suspecting as much yesterday so I left it running overnight on
ARM. It managed to get to stage comparison but failed due to many differences.
But not before I'd got impatient in the morning and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77917
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77917
--- Comment #8 from Andrew Pinski ---
(In reply to PeteVine from comment #7)
> BTW, I sincerely hope `--with-build-config=bootstrap-lto` is not derailed by
> the presence of `-flto` among environment C(XX)FLAGS, as otherwise it
> definitely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77917
--- Comment #7 from PeteVine ---
BTW, I sincerely hope `--with-build-config=bootstrap-lto` is not derailed by
the presence of `-flto` among environment C(XX)FLAGS, as otherwise it
definitely makes sense for configure to always sanitize those
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77917
--- Comment #6 from PeteVine ---
Indeed, gold is definitely a factor, but look what happens after switching back
to ld.bfd on ARM:
make[6]: Entering directory
`/home/guest/gcc-svn-master/build/arm-linux-gnueabihf/libstdc++-v3/src'
/bin/bash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77917
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
