<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 27, 2013 at 4:07 PM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank" class="cremed">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"><div class="im">On 27 October 2013 15:53, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank" class="cremed">clattner@apple.com</a>></span> wrote:<br>
<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div><span style="color:rgb(34,34,34)">I'm not sure what you mean.  Are your proposing that clang 3.4 use any features supported by clang 3.3?  If so, that won't work, because clang can't self-host on all interesting architectures, e.g. it isn't fully ABI compatible with Visual C++ (yet).</span></div>

</div></div></blockquote><div></div></div><br></div></div><div class="gmail_extra">No, not yet. Certainly not for 3.4!</div><div class="gmail_extra"><br></div><div class="gmail_extra">My comment was more to the effect that we could use this as a target for the future (and probably never achieve it), thus why "design guideline" and not a developer policy.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">We'll have to make sure we can do it on all "interesting" architectures first (given all constraints).</div></blockquote></div><br>I think that just establishing a floor on the problem (a soft one, which naturally has to be interpreted based on the realities at the time) is the best first step. I *don't* want to lose the ability to host LLVM and Clang with reasonably modern C++ toolchains that are not Clang-derived. I *do* want to set expectations with clear guidelines for what we consider "reasonably modern" to be.</div>
</div>