<div dir="ltr">Hi,<br><br><div class="gmail_extra"><div class="gmail_quote">On Wed, Nov 6, 2013 at 6:20 PM,  <span dir="ltr"><<a href="mailto:dag@cray.com" target="_blank">dag@cray.com</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">David Tweed <<a href="mailto:david.tweed@gmail.com">david.tweed@gmail.com</a>> writes:<br>
<br>
> A personal question: is there any way we could modify some part of the<br>
> build to do some of the "non-fatal but difficult to ignore"<br>
> announcement if the building compiler can't handle the upcoming<br>
> constructs? Eg, just thinking off the top of my head here, could we<br>
> abuse the make check/lit mechanism to get a file with C++11 features<br>
> that are going to be used in X months compiled with the building<br>
> compiler, so that people running projects following ToT and who run<br>
> "make check" regularly will get a new failure if they'll be facing<br>
> problems ahead?<br>
<br>
</div>This wouldn't address the main issue as I see it.  I am not worried at<br>
all about LLVM and whether I'll be able to build it with a new toolchain<br>
on our machines.  I'm worried about everything *else* we have integrated<br>
with LLVM that will also need to be built with the new toolchain.  It's<br>
all that other stuff that we need to be able to test before LLVM forces<br>
us to use a new toolchain.<br>
<br>
When the LLVM 3.4 release is cut, I'm simply asking that we don't start<br>
using stuff that requires a new toolchain right away.  If we could wait<br>
3-4 months that would allow time for testing.  We can still require a<br>
new toolchain for the 3.5 release, allow C++-11, etc..  We just<br>
shouldn't require it on ToT right away.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div>Fair enough: my concern was that we haven't heard much from other people who are following ToT but aren't primarily LLVM developers in this discussion, yet I talk to a lot of people who say they pull in ToT quite regularly. So the thing that was concerning me was that an email gets sent to the dev mailing list announcing this. Maybe the affected people will read it, maybe they won't (I know I don't have the time to do more than skim the mailing lists). At least with some big smoking gun in the code it's easier to persuade management this is a serious issue that needs time budgetting for investigation NOW.<br>
<br>But I entirely appreciate that the problem may be that everyone knows but still needs time to do due diligence on a new toolchain.<br></div></div>-- <br><div>cheers, dave tweed__________________________</div><div>high-performance computing and machine vision expert: <a href="mailto:david.tweed@gmail.com" target="_blank">david.tweed@gmail.com</a></div>
<div>"while having code so boring anyone can maintain it, use Python." -- attempted insult seen on slashdot</div><div> </div>
</div></div>