https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81733
--- Comment #4 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to r...@cebitec.uni-bielefeld.de from comment #3) > > --- Comment #1 from Iain Sandoe <iains at gcc dot gnu.org> --- > > Is this still current? > > It is: just tried with a vanilla tree at r252892. > > > The ld64 assert is most likely triggered by a 0-length FDE. That could be > > caused by confusion over the partitioning. > > That's certainly true considering the hack I'm using to allow bootstrap > to finish. > > I don't see this on 10.11.6 with my bootstrap setup, what version of ld64 / > > cctools / bootstrap compiler are you using? > > I'm on 10.11.2, ld64 is ld64-128.2 (but I also tried with the ld64 from > your darwin-xtools repo on github, ld64-253.9, with same results). OK. I do have a patch to make ld64 drop 0-length FDEs silently (but, in some respects, it's probably actually better to have the assert - since it probably indicates something is wrong earlier in the toolchain). > Bootstrapping with gcc 7.1.0. OK.. let me see if I can reproduce - I can certainly see bad EH being generated with the bootstrap toolchain I'm using (but it doesn't kill bootstrap for me). Things a bit hectic this week, but will try to fit it in. I had some patches to make the partitioning output more ld64-atom-friendly, but they didn't rebase cleanly (some turbulence in the hot/cold partitioning stuff), so it will take some more analysis to re-apply them - hope is that they will squash some of the problems, and then we just need to analyse the rest.. incidentally, probably, 80556 is caused by the libgcc_eh unwinder being broken itself from this (since -static-libgcc _should_ work providing there's _only_ the libgcc unwinder in use).
