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