https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267
--- Comment #51 from Iain Sandoe <iains at gcc dot gnu.org> --- (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...
