<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 28, 2016 at 12:50 PM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 28 October 2016 at 20:35, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>
> That's actually part of a much larger pattern: Clang is currently set up to<br>
> act as a drop-in replacement for the system compiler. That means we use<br>
> libstdc++ (not libc++) by default on targets where it's the default C++<br>
> standard library, we use libgcc_s (not compiler-rt) by default on targets<br>
> where it's the default compiler runtime, and so on. That strategy has worked<br>
> well in getting us to where we are today.<br>
<br>
</span>Agreed! And I still need this very much to work.<br>
<span class=""><br>
<br>
> But our needs today aren't the same as they were a few years ago; we don't<br>
> need to prove ourselves as much as we used to, and while we should keep<br>
> supporting the target defaults for the above components, perhaps it's time<br>
> that we start to prefer using LLVM components where available.<br>
<br>
</span>My feelings exactly.<br>
<span class=""><br>
<br>
> At the very<br>
> least, I don't see a good reason why we would ever want to use libgcc_s in a<br>
> situation where compiler-rt (and libunwind) are available -- libgcc_s does<br>
> not contain some functions that LLVM implicitly adds calls to.<br>
<br>
</span>That's another dead-lock we need to solve, yes. :(<br>
<span class=""><br>
<br>
> Perhaps we should have a flag to specify whether we prefer the canonical<br>
> tools and components for the target, or whether we prefer LLVM's versions<br>
> when available (falling back to the target components if not)?<br>
<br>
</span>Hum, I had't thought of this...<br>
<br>
Do you mean a flag that would (try) to use as much of LLVM as<br>
possible, and fall back to the system's tools when unavailable?<br></blockquote><div><br></div><div>Either that or a flag that specifies to prefer the system's tools, with the default behavior being to use LLVM's tools when possible.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I like the idea very much, but I wonder the kind of spurious bugs<br>
we'll see if one tool suddenly doesn't get built, or change location,<br>
or $PATH changes.</blockquote><div><br></div><div>That problem already exists; we search various paths looking for tools, libstdc++, and so on. It doesn't seem to be a particularly big deal in practice, and it's easy to ask Clang to tell you what it actually selected.</div></div></div></div>