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

Wed Oct 12 16:03:19 PDT 2016

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/20161012/25c207ca/attachment.html>