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

Tue Oct 18 00:13:24 PDT 2016

No blocker from me! Thanks for your patience!
On Tue, 18 Oct 2016 at 00:18, Mehdi Amini <mehdi.amini at apple.com> wrote:

> 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: [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
>
> 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-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>
> 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> 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 ).
>
> —
> Mehdi
>
>
> On Sep 8, 2016, at 8:38 AM, James Molloy via llvm-dev <
> 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> wrote:
>
> On Thu, Sep 8, 2016 at 11:24 AM, Reid Kleckner via llvm-dev
> <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> 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] 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
> >> 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> 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> 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/
> >>
> >> 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> 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> 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> wrote:
> >>
> >> On Sep 1, 2016, at 1:05 PM, Reid Kleckner <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> 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
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >>
> >> _______________________________________________
> >> cfe-dev mailing list
> >> cfe-dev at lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >>
> >>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >>
> >> LLVM Developers mailing list
> >>
> >> llvm-dev at lists.llvm.org
> >>
> >> 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
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org
> >> 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
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> 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/20161018/89acf230/attachment-0001.html>