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 did
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 makes
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 flag
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 ../l
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
