<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal" style="margin-left:.5in">Community is fine for anyone to use, even corporations, for free, as long as it is for an open source project. IANAL, but it says it in Section 1.b.1
<a href="https://www.visualstudio.com/support/legal/mt171547">here</a>.<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">While LLVM per se is an open-source project, the toolchain I actually deliver to my licensees is not. IANAL either but I believe
"Community" is not a solution for us, for that reason.<o:p></o:p></span></a></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">--paulr<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> llvm-dev [mailto:llvm-dev-bounces@lists.llvm.org]
<b>On Behalf Of </b>Zachary Turner via llvm-dev<br>
<b>Sent:</b> Thursday, September 01, 2016 12:36 PM<br>
<b>To:</b> Nico Weber<br>
<b>Cc:</b> llvm-dev; cfe-dev@lists.llvm.org<br>
<b>Subject:</b> Re: [llvm-dev] [cfe-dev] Revisiting our informal policy to support two versions of MSVC<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">I guess what I'm getting at, is why do we even need to support 2 toolchains with LLVM *at all*? Why can't we just always upgrade to the newest one unless there are serious issues with it?<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">There used to be two reasons that I'm aware of:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">1) Licensing. Community used to be Express, and Express used to be limited in functionality. But this is no longer the case. Community is fine for anyone to use, even corporations, for free, as long as it is for an open source project.
IANAL, but it says it in Section 1.b.1 <a href="https://www.visualstudio.com/support/legal/mt171547">
here</a>.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">2) Library toolchain mismatches. It used to be that in order to link against a library, it had to be compiled with the same toolchain. So someone whose application was built with VS 2012 couldn't link against LLVM built with VS 2013,
they would have to build LLVM themselves with VS2012, so dropping support for 2012 would harm them. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">But beginning with Visual Studio 2015, because of the UCRT, this is no longer the case. All versions of the CRT will be forward compatible.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">So if we're going to upgrade to VS 2015, why not also just upgrade to VS 15 as soon as possible? Once VS 2015 is the minimum, it doesn't seem like we should worry too much about upgrading compiler versions anymore (aside from the effort
to actually do it and make sure it works and the compiler bugs and issues are known about).<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Thu, Sep 1, 2016 at 12:24 PM Nico Weber <<a href="mailto:thakis@chromium.org">thakis@chromium.org</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p class="MsoNormal">On Thu, Sep 1, 2016 at 3:16 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal">I don't see how the policy of supporting 2 versions is related to that difficulty though. Whether we support 1 versions or 2 versions, 1 version is still going to be deprecated every time a new version is released. So this burden on upgrading
buildbots doesn't seem to be much different. <br>
<br>
As long as chromium compiler version is not tied to llvm compiler version (and if it did, that would be a chromium decision not an llvm one) this is always going to be a problem whether llvm supports newest compiler or newest 2 compilers<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">I think in general the world is trying to update to new toolchains, it just takes a while. With LLVM's old policy, Chromium always updated faster than LLVM so far.<o:p></o:p></p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Thu, Sep 1, 2016 at 12:09 PM Nico Weber <<a href="mailto:thakis@chromium.org" target="_blank">thakis@chromium.org</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p class="MsoNormal">On Thu, Sep 1, 2016 at 3:03 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal">I frequently see mention of how upgrading is problematic, is there anyone here for whom upgrading msvc versions is problematic? It seems like we keep talking in hypotheticals, but I'd like to hear from someone for whom it is *actually*
a problem, and why.<br>
<br>
Vs community is permissive enough now that licensing isn't an issue. And every time this comes up it seems like we're saying "well it could be hard for people..." but nobody ever says it actually is hard for them specifically
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">I just said that in the mail you're replying to (?) Having to update our ~20 Windows bots so that they use a different MSVC than what's on there already for Chromium is going to be actually hard for us.<o:p></o:p></p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<div>
<p class="MsoNormal">On Thu, Sep 1, 2016 at 11:16 AM Aaron Ballman via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">On Thu, Sep 1, 2016 at 2:08 PM, Nico Weber <<a href="mailto:thakis@chromium.org" target="_blank">thakis@chromium.org</a>> wrote:<br>
> On Thu, Sep 1, 2016 at 1:30 PM, Aaron Ballman <<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>><br>
> wrote:<br>
>><br>
>> On Thu, Sep 1, 2016 at 1:23 PM, Nico Weber via cfe-dev<br>
>> <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
>> > As mentioned upthread, we're still on update 2 for various reasons.<br>
>><br>
>> Do you mind elaborating on those reasons?<br>
><br>
><br>
> Off the top of my head, clang-cl couldn't handle the code generated by the<br>
> midl compiler in that version until fairly recently, and we've been seeing<br>
> link.exe /INCREMENTAL failing intermittently (no reliable repro case<br>
> though).<br>
<br>
Thank you for the extra information.<br>
<br>
><br>
>><br>
>> I think we should require<br>
>> the latest updates to MSVC due to the number of issues the updates fix<br>
>> (esp regarding the newer language features that people keep using so<br>
>> frequently), but I've also not heard a concrete use case as to why we<br>
>> shouldn't.<br>
><br>
><br>
> Do you mean "require latest updates" in general, or just in this case?<br>
> Updating immediately every time a new MSVS release comes out would<br>
> definitely be tricky for us.<br>
<br>
I mean in general, but "immediate" wasn't what I had in mind. More<br>
like "within some reasonable time frame", for whatever definition of<br>
reasonable works for people. Given how often Microsoft fixes critical<br>
language bugs with newer features during an Update release, I'm hoping<br>
we can avoid sticking to older Updates if we are able to do so.<br>
<br>
~Aaron<br>
<br>
><br>
>><br>
>><br>
>> ~Aaron<br>
>><br>
>> ><br>
>> > On Thu, Sep 1, 2016 at 1:07 PM, Robinson, Paul <<a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> Hi Reid, first off thanks *very* much for all your help fixing<br>
>> >> 2013-related problems. We really appreciate it.<br>
>> >><br>
>> >><br>
>> >><br>
>> >> Let me propose a target date of September 15 for advancing the minimum<br>
>> >> MS<br>
>> >> compiler to VS2015 Update 3. Certainly my team should be ready by<br>
>> >> then. If<br>
>> >> anybody else needs a later date, in particular people who own Windows<br>
>> >> bots<br>
>> >> still using VS2013, please speak up.<br>
>> >><br>
>> >> --paulr<br>
>> >><br>
>> >><br>
>> >><br>
>> >> From: Reid Kleckner [mailto:<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>]<br>
>> >> Sent: Wednesday, August 31, 2016 4:07 PM<br>
>> >> To: Robinson, Paul<br>
>> >> Cc: James Molloy; Nico Weber; llvm-dev; <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">
cfe-dev@lists.llvm.org</a><br>
>> >> Subject: Re: [llvm-dev] [cfe-dev] Revisiting our informal policy to<br>
>> >> support two versions of MSVC<br>
>> >><br>
>> >><br>
>> >><br>
>> >> I'd like to revisit this. As a person who spends a fair amount of time<br>
>> >> monitoring our VS 2013 buildbots, I would say that I am ready to throw<br>
>> >> in<br>
>> >> the towel on MSVC 2013. Since this discussion, I have committed five<br>
>> >> (!)<br>
>> >> workarounds for MSVC 2013:<br>
>> >><br>
>> >><br>
>> >><br>
>> >> # in llvm<br>
>> >><br>
>> >> $ git log --author=rnk --grep=2013 --after='Aug 4 2016' --oneline<br>
>> >><br>
>> >> 21a8ade Fix the MSVC 2013 build by using Elf_Word instead of making a<br>
>> >> local typedef<br>
>> >><br>
>> >> 27e101d Revert "Add an optional parameter with a list of undefs to<br>
>> >> extendToIndices"<br>
>> >><br>
>> >> e8beddd Make vec_fabs.ll pass with MSVC 2013<br>
>> >><br>
>> >> ca77873 [AMDGPU] Give enum an explicit 64-bit type to fix MSVC 2013<br>
>> >> failures<br>
>> >><br>
>> >><br>
>> >><br>
>> >> # in clang<br>
>> >><br>
>> >> $ git log --author=rnk --grep=2013 --after='Aug 4 2016' --oneline<br>
>> >><br>
>> >> 18235a5 Try to work around an MSVC 2013 bug around defaulted default<br>
>> >> ctors<br>
>> >><br>
>> >><br>
>> >><br>
>> >> I'm pretty sure I'm missing instances where I helped others commit<br>
>> >> workarounds as well. So, I'd really like to drop 2013, probably<br>
>> >> sometime<br>
>> >> next month.<br>
>> >><br>
>> >><br>
>> >><br>
>> >> That said, I'd also like to echo Paul's sentiment that it'd help if<br>
>> >> people<br>
>> >> were less adventurous in their uses of C++11. New language features may<br>
>> >> look<br>
>> >> nice, but ultimately you may end up wasting my time and yours when I<br>
>> >> come<br>
>> >> and revert your change.<br>
>> >><br>
>> >><br>
>> >><br>
>> >> On Thu, Aug 4, 2016 at 7:52 AM, Robinson, Paul via llvm-dev<br>
>> >> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>> >><br>
>> >> I've heard from another group within Sony that they had "a number of<br>
>> >> problems" with VS2015 update 2, and strongly recommend going straight<br>
>> >> to<br>
>> >> update 3. My immediate team has initiated a request but it hasn't gone<br>
>> >> through yet.<br>
>> >><br>
>> >> --paulr<br>
>> >><br>
>> >><br>
>> >><br>
>> >> From: James Molloy [mailto:<a href="mailto:james@jamesmolloy.co.uk" target="_blank">james@jamesmolloy.co.uk</a>]<br>
>> >> Sent: Wednesday, August 03, 2016 1:54 AM<br>
>> >> To: Nico Weber; Robinson, Paul<br>
>> >> Cc: llvm-dev; <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
>> >> Subject: Re: [cfe-dev] [llvm-dev] Revisiting our informal policy to<br>
>> >> support two versions of MSVC<br>
>> >><br>
>> >><br>
>> >><br>
>> >> Hi,<br>
>> >><br>
>> >><br>
>> >><br>
>> >> This sounds like a decent idea to me. However we use 2013 for all our<br>
>> >> windows builds at the moment and it will take around 2 weeks to upgrade<br>
>> >> the<br>
>> >> installations on our cluster. We're pushing this hard to get it done<br>
>> >> soon so<br>
>> >> we don't get caught short, but a grace period would be much<br>
>> >> appreciated.<br>
>> >><br>
>> >><br>
>> >><br>
>> >> Cheers,<br>
>> >><br>
>> >><br>
>> >><br>
>> >> James<br>
>> >><br>
>> >><br>
>> >><br>
>> >> On Tue, 2 Aug 2016 at 21:24 Nico Weber via cfe-dev<br>
>> >> <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
>> >><br>
>> >> On Tue, Aug 2, 2016 at 3:49 PM, Robinson, Paul via cfe-dev<br>
>> >> <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
>> >><br>
>> >> For my project, timing is everything. We (and I could easily imagine,<br>
>> >><br>
>> >> for many downstream projects) lead time is important.<br>
>> >><br>
>> >><br>
>> >><br>
>> >> In Chromium land, we've so far been able to use the same compiler we<br>
>> >> use<br>
>> >> to build Chrome to build clang. Currently that's MSVS2015 update 2, and<br>
>> >> it<br>
>> >> took quite a while to update from 2013 to 2015 due bugs in 2015 and<br>
>> >> whatnot.<br>
>> >> So I agree that it's useful to support older MSVS versions for some<br>
>> >> time.<br>
>> >> For this reason, requiring update 3 would be inconvenient for us, but<br>
>> >> 2015u2<br>
>> >> would be no problem by now. It would've been a problem if 2015 had been<br>
>> >> required shortly after it was released.<br>
>> >><br>
>> >><br>
>> >><br>
>> >> Nico<br>
>> >><br>
>> >> _______________________________________________<br>
>> >> cfe-dev mailing list<br>
>> >> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
>> >> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
>> >><br>
>> >><br>
>> >> _______________________________________________<br>
>> >> LLVM Developers mailing list<br>
>> >> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>> >> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
>> >><br>
>> >><br>
>> ><br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > cfe-dev mailing list<br>
>> > <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
>> > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
>> ><br>
><br>
><br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</body>
</html>