[llvm-dev] [cfe-dev] Revisiting our informal policy to support two versions of MSVC

Mon Oct 17 16:18:30 PDT 2016

Hi,

If there is no blocker (James?), we should be able to move on, so I filed as a starter: https://reviews.llvm.org/D25710 <https://reviews.llvm.org/D25710>: [Doc] Drop MSVC2013 support

— 
Mehdi


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161017/18b03f7e/attachment.html>