[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977

[howarth.at.gcc at gmail dot com]

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 ro@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.