Thank you both, we appreciate it a lot!<br><div class="gmail_quote"><div dir="ltr">On Thu, 8 Sep 2016 at 16:37, Aaron Ballman via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Sep 8, 2016 at 11:24 AM, Reid Kleckner via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> I can't say I'm excited to support MSVC 2013 for another month, but I'm more<br>
> concerned about the burden on other developers. People I talked to at the SF<br>
> bay area social last Thursday were really excited to drop 2013 support. I<br>
> guess I'll leave my buildbots on another month and see how it goes.<br>
<br>
I'm happy to help carry the burden as well, so if you run into<br>
anything you'd like to punt over to me, please let me know. I'm happy<br>
to handle it in addition to the things I usually pick up on.<br>
<br>
~Aaron<br>
<br>
><br>
> On Thu, Sep 8, 2016 at 7:03 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>
>> As this is an ABI-incompatible upgrade, and it's changing the informal<br>
>> policy on upgrades, could we please have some more grace time? Ideally<br>
>> another month, so the 15th October. If we haven't sorted it by then, it's<br>
>> our problem.<br>
>><br>
>><br>
>><br>
>> I had originally proposed 15 September mostly because nobody had proposed<br>
>> a specific date, and it has been kind of dragging on for a while.  The<br>
>> primary cost of deferring to 15 October seems to be that the community (Hi<br>
>> Reid!) will have to keep fixing VS2013 related problems for another month,<br>
>> which isn't ideal but hopefully we can tolerate it.<br>
>><br>
>> (In fact at Sony we're only throwing the internal switch today, and we'll<br>
>> have to see what happens.)<br>
>><br>
>> --paulr<br>
>><br>
>><br>
>><br>
>> From: llvm-dev [mailto:<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>] On Behalf Of<br>
>> Craig, Ben via llvm-dev<br>
>> Sent: Wednesday, September 07, 2016 2:42 PM<br>
>> To: Zachary Turner; James Molloy; <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-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'll need to dig up the references for that... but I'm pretty sure the<br>
>> universal CRT that debuted in MSVC 2015 only covers the C parts, and not the<br>
>> C++ parts.<br>
>><br>
>><br>
>><br>
>> On 9/7/2016 4:28 PM, Zachary Turner wrote:<br>
>><br>
>> It's worth pointing out that from 2015 and on, they claim to support full<br>
>> forwards compatibility of the standard libraries, so this should (in theory)<br>
>> never be an issue again.<br>
>><br>
>><br>
>><br>
>> On Wed, Sep 7, 2016 at 1:12 PM James Molloy via llvm-dev<br>
>> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> As I understand it the specific issue we're seeing is related to what<br>
>> Martin described. But due to numerous bugs found when mixing objects<br>
>> compiled with different versions of MSVC in the past, we now are shy of<br>
>> doing it even if it seems to work superficially - that's no guarantee bugs<br>
>> won't be found down the line. We'd much prefer to stay within the realms of<br>
>> what Microsoft support.<br>
>><br>
>> Cheers,<br>
>><br>
>> James<br>
>><br>
>> On Wed, 7 Sep 2016 at 20:53, Craig, Ben via llvm-dev<br>
>> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> Note that this is intentional from the MSVC C++ library implementation<br>
>> side of things.  For major versions, no attempt is made to preserve library<br>
>> ABI compatibility.<br>
>><br>
>> I am aware of a language ABI break in VC++ 2013.<br>
>> <a href="https://randomascii.wordpress.com/2013/12/01/vc-2013-class-layout-change-and-wasted-space/" rel="noreferrer" target="_blank">https://randomascii.wordpress.com/2013/12/01/vc-2013-class-layout-change-and-wasted-space/</a><br>
>><br>
>> I'm not currently aware of any on the VC++ 2015 side of things, but that<br>
>> doesn't mean much.<br>
>><br>
>><br>
>><br>
>> On 9/7/2016 2:34 PM, Martin O'Riordan via llvm-dev wrote:<br>
>><br>
>> Apart from the obvious licencing issues, each time I have moved from one<br>
>> version of VC++ to another, the big problem I have had is not specifically<br>
>> the ABI at the register passing, stack organisation level, but rather the<br>
>> implementation details of the Standard C++ libraries, and in particular the<br>
>> STL containers.<br>
>><br>
>> While the compiler team puts considerable effort into maintaining the ABI,<br>
>> the C++ library implementation usually changes a lot.<br>
>><br>
>> Since this is largely in the form of very complex headers defining<br>
>> templates which in turn cause other helper templates to be used, it is here<br>
>> that I find things go awry.<br>
>><br>
>> So for C++, a function like:<br>
>><br>
>> std::list<int> foo();<br>
>><br>
>><br>
>><br>
>> seems simple enough, but if the caller and the callee are compiled with<br>
>> different versions, it usually won't work because of some artefact of the<br>
>> STL implementation tuning that occurs between versions.  In particular, this<br>
>> impacts things like using C++ interfaces across DLLs and in pre-compiled<br>
>> libraries.<br>
>><br>
>> I think that the ABI maintenance in this case tends to be for C and POD<br>
>> compatability, but not for the higher level C++ compatability which is<br>
>> unfortunate and restricts how we can use C++.<br>
>><br>
>> Is it possible that it is this aspect of the version change that is<br>
>> causing your ABI difficulties?<br>
>><br>
>> MartinO<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> On 7 September 2016 at 20:18, Zachary Turner via llvm-dev<br>
>> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> Can you elaborate on the abi incompatibility? I thought there were no<br>
>> breaks<br>
>><br>
>> On Wed, Sep 7, 2016 at 7:59 AM James Molloy via cfe-dev<br>
>> <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> Hi all,<br>
>><br>
>><br>
>><br>
>> Firstly sorry I'm a bit late responding on this one. Internally to ARM we<br>
>> build LLVM for Windows. Our current build cluster has only VS2013 installed<br>
>> and as a result of this thread we've been working on getting VS2015<br>
>> installed. This involves a certain amount of IT-wrangling as the cluster we<br>
>> use is company-wide. There have been some hiccups regarding licensing of<br>
>> MSVC professional (we can't use the community edition for the same reasons<br>
>> mentioned by Paul previously) but we hoped to be ready in time for the 15th<br>
>> September switchover date.<br>
>><br>
>><br>
>><br>
>> It's recently been realised that VS2013 and VS2015 are not ABI compatible<br>
>> (something that really surprised me), and this means we have to synchronize<br>
>> moving LLVM's build to VS2015 as well as upgrading a third party library<br>
>> that we receive from the vendor in compiled library form. This is not<br>
>> something we're capable of doing by September 15th.<br>
>><br>
>><br>
>><br>
>> We try really hard at ARM to hide our internal processes because we<br>
>> believe that they're on the whole irrelevant to the community, however in<br>
>> this case we'd be really stuck, unable to get production builds.<br>
>><br>
>><br>
>><br>
>> As this is an ABI-incompatible upgrade, and it's changing the informal<br>
>> policy on upgrades, could we please have some more grace time? Ideally<br>
>> another month, so the 15th October. If we haven't sorted it by then, it's<br>
>> our problem.<br>
>><br>
>><br>
>><br>
>> Cheers,<br>
>><br>
>><br>
>><br>
>> James<br>
>><br>
>><br>
>><br>
>> On Thu, 1 Sep 2016 at 21:06 Mehdi Amini via cfe-dev<br>
>> <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> On Sep 1, 2016, at 1:05 PM, Reid Kleckner <<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>> wrote:<br>
>><br>
>><br>
>><br>
>> On Thu, Sep 1, 2016 at 12:53 PM, Mehdi Amini via cfe-dev<br>
>> <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> Isn’t a big (the most) reason for supporting “old” toolchains to allow<br>
>> downstream users to upgrade with some flexibility?<br>
>><br>
>> If I have a large codebase that is using LLVM (let say a few custom<br>
>> backends), and is validated with “MSVC 2013”, I can upgrade to “2015” but I<br>
>> will need some qualification/validation: this is not free and take some<br>
>> time. If you drop aggressively supports for “old” toolchain it means that<br>
>> I’m either stuck with an “old” LLVM or that I have to update earlier than<br>
>> expected.<br>
>><br>
>><br>
>><br>
>> Isn’t this usually balanced in upstream LLVM to upgrade when there is a<br>
>> real *benefit* to it?<br>
>><br>
>> I’m mentioning it because it seems to conflict with the "always upgrade to<br>
>> the newest one unless there are serious issues with it” you mentioned above.<br>
>><br>
>><br>
>><br>
>> I agree, we should raise the minimum VS version requirement when the<br>
>> benefits to the LLVM community outweigh the costs of switching for major<br>
>> LLVM contributors and users. I think we'll always make that decision in the<br>
>> same way: by raising it on the mailing lists and discussing the pros and<br>
>> cons. That's basically what David said when he kicked this whole discussion<br>
>> off, anyway:<br>
>><br>
>><br>
>><br>
>> """But if we find ourselves in a situation where asking folks to upgrade<br>
>> to a compiler which has been widely deployed soothes development for the<br>
>> greater LLVM community, we should consider dropping support for the older<br>
>> versions of that compiler."""<br>
>><br>
>><br>
>><br>
>> I think everything is working as intended here.<br>
>><br>
>><br>
>><br>
>> Right, to be clear there is no misunderstanding: I was absolutely not<br>
>> suggesting the opposite when answering Zach..<br>
>><br>
>><br>
>><br>
>> —<br>
>><br>
>> Mehdi<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> We raised the VS 2013 upgrade issue, discussed it, determined that it was<br>
>> holding us back, and now we're doing the upgrade. If VS "15" brings major<br>
>> language compatibility improvements, I imagine we'll be having this same<br>
>> discussion again next year. If it doesn't, and supporting 2015 and "15" at<br>
>> the same time has the same cost, then we won't bother raising the floor for<br>
>> a while.<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" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><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" rel="noreferrer" 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" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>><br>
>> LLVM Developers mailing list<br>
>><br>
>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>><br>
>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
>><br>
>><br>
>><br>
>> --<br>
>><br>
>> Employee of Qualcomm Innovation Center, Inc.<br>
>><br>
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux<br>
>> Foundation Collaborative Project<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" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><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" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
>><br>
>><br>
>><br>
>> --<br>
>><br>
>> Employee of Qualcomm Innovation Center, Inc.<br>
>><br>
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux<br>
>> Foundation Collaborative Project<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" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
>><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" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><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" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>