https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267
--- Comment #52 from Jack Howarth <howarth.at.gcc at gmail dot com> --- (In reply to Iain Sandoe from comment #51) > (In reply to r...@cebitec.uni-bielefeld.de from comment #50) > > > --- Comment #49 from Iain Sandoe <iains at gcc dot gnu.org> --- > > [...] > > > I can do darwin14 (I built 242408 last night with the patches-in-progress > > > + > > > __BLOCKS__) but that's a little bit more than the minimum > > > (darwin_availabilityinternal + __BLOCKS__) > > > > > > choice 1. Rainer splits out the minimum (darwin_availabilityinternal) > > > from his > > > original patch and we put that together with the __BLOCKS__ one. > > > > > > choice 2. Rainer posts his current patch (which is at least correcting > > > some of > > > the problems, even if not complete) and we apply that together with the > > > __BLOCKS__ one. > > > > Right now, I've got nothing beyond > > > > https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01348.html > > > > Once we hit the Darwin 15 roadblock with _os_trace_with_buffer being > > unavailable, I didn't try further and also didn't start looking into the > > Darwin 14 issues. > > > > I think choice 2 is right: the fixincludes fixes all fix real issues in > > system headers, libsanitizer nonewithstanding. We can develop further > > fixes for Darwin 14 later, even if they are not needed to get > > libsanitizer to build. > > > > If we go this route, we know that it works on Darwin 16 (tested by > > myself; it does even with the __BLOCKS__ one) and 15 (Jack confirmed > > this). If you can check on 14, I think we're set for now. > > I guess both parts have been approved independently... Confirmed that choice 2 (both parts) completes a 3-stage bootstrap with comparison on darwin14.
