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

Nico Weber via llvm-dev llvm-dev at lists.llvm.org
Thu Sep 1 12:09:11 PDT 2016


On Thu, Sep 1, 2016 at 3:03 PM, Zachary Turner <zturner at google.com> wrote:

> I frequently see mention of how upgrading is problematic, is there anyone
> here for whom upgrading msvc versions is problematic? It seems like we keep
> talking in hypotheticals, but I'd like to hear from someone for whom it is
> *actually* a problem, and why.
>
> Vs community is permissive enough now that licensing isn't an issue. And
> every time this comes up it seems like we're saying "well it could be hard
> for people..." but nobody ever says it actually is hard for them
> specifically
>

I just said that in the mail you're replying to (?) Having to update our
~20 Windows bots so that they use a different MSVC than what's on there
already for Chromium is going to be actually hard for us.


> On Thu, Sep 1, 2016 at 11:16 AM Aaron Ballman via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> On Thu, Sep 1, 2016 at 2:08 PM, Nico Weber <thakis at chromium.org> wrote:
>> > On Thu, Sep 1, 2016 at 1:30 PM, Aaron Ballman <aaron at aaronballman.com>
>> > wrote:
>> >>
>> >> On Thu, Sep 1, 2016 at 1:23 PM, Nico Weber via cfe-dev
>> >> <cfe-dev at lists.llvm.org> wrote:
>> >> > As mentioned upthread, we're still on update 2 for various reasons.
>> >>
>> >> Do you mind elaborating on those reasons?
>> >
>> >
>> > Off the top of my head, clang-cl couldn't handle the code generated by
>> the
>> > midl compiler in that version until fairly recently, and we've been
>> seeing
>> > link.exe /INCREMENTAL failing intermittently (no reliable repro case
>> > though).
>>
>> Thank you for the extra information.
>>
>> >
>> >>
>> >> I think we should require
>> >> the latest updates to MSVC due to the number of issues the updates fix
>> >> (esp regarding the newer language features that people keep using so
>> >> frequently), but I've also not heard a concrete use case as to why we
>> >> shouldn't.
>> >
>> >
>> > Do you mean "require latest updates" in general, or just in this case?
>> > Updating immediately every time a new MSVS release comes out would
>> > definitely be tricky for us.
>>
>> I mean in general, but "immediate" wasn't what I had in mind. More
>> like "within some reasonable time frame", for whatever definition of
>> reasonable works for people. Given how often Microsoft fixes critical
>> language bugs with newer features during an Update release, I'm hoping
>> we can avoid sticking to older Updates if we are able to do so.
>>
>> ~Aaron
>>
>> >
>> >>
>> >>
>> >> ~Aaron
>> >>
>> >> >
>> >> > On Thu, Sep 1, 2016 at 1:07 PM, Robinson, Paul <
>> paul.robinson at sony.com>
>> >> > wrote:
>> >> >>
>> >> >> Hi Reid, first off thanks *very* much for all your help fixing
>> >> >> 2013-related problems.  We really appreciate it.
>> >> >>
>> >> >>
>> >> >>
>> >> >> Let me propose a target date of September 15 for advancing the
>> minimum
>> >> >> MS
>> >> >> compiler to VS2015 Update 3.  Certainly my team should be ready by
>> >> >> then. If
>> >> >> anybody else needs a later date, in particular people who own
>> Windows
>> >> >> bots
>> >> >> still using VS2013, please speak up.
>> >> >>
>> >> >> --paulr
>> >> >>
>> >> >>
>> >> >>
>> >> >> From: Reid Kleckner [mailto:rnk at google.com]
>> >> >> Sent: Wednesday, August 31, 2016 4:07 PM
>> >> >> To: Robinson, Paul
>> >> >> Cc: James Molloy; Nico Weber; llvm-dev; cfe-dev at lists.llvm.org
>> >> >> Subject: Re: [llvm-dev] [cfe-dev] Revisiting our informal policy to
>> >> >> support two versions of MSVC
>> >> >>
>> >> >>
>> >> >>
>> >> >> I'd like to revisit this. As a person who spends a fair amount of
>> time
>> >> >> monitoring our VS 2013 buildbots, I would say that I am ready to
>> throw
>> >> >> in
>> >> >> the towel on MSVC 2013. Since this discussion, I have committed five
>> >> >> (!)
>> >> >> workarounds for MSVC 2013:
>> >> >>
>> >> >>
>> >> >>
>> >> >> # in llvm
>> >> >>
>> >> >> $ git log --author=rnk --grep=2013  --after='Aug 4 2016' --oneline
>> >> >>
>> >> >> 21a8ade Fix the MSVC 2013 build by using Elf_Word instead of making
>> a
>> >> >> local typedef
>> >> >>
>> >> >> 27e101d Revert "Add an optional parameter with a list of undefs to
>> >> >> extendToIndices"
>> >> >>
>> >> >> e8beddd Make vec_fabs.ll pass with MSVC 2013
>> >> >>
>> >> >> ca77873 [AMDGPU] Give enum an explicit 64-bit type to fix MSVC 2013
>> >> >> failures
>> >> >>
>> >> >>
>> >> >>
>> >> >> # in clang
>> >> >>
>> >> >> $ git log --author=rnk --grep=2013  --after='Aug 4 2016' --oneline
>> >> >>
>> >> >> 18235a5 Try to work around an MSVC 2013 bug around defaulted default
>> >> >> ctors
>> >> >>
>> >> >>
>> >> >>
>> >> >> I'm pretty sure I'm missing instances where I helped others commit
>> >> >> workarounds as well. So, I'd really like to drop 2013, probably
>> >> >> sometime
>> >> >> next month.
>> >> >>
>> >> >>
>> >> >>
>> >> >> That said, I'd also like to echo Paul's sentiment that it'd help if
>> >> >> people
>> >> >> were less adventurous in their uses of C++11. New language features
>> may
>> >> >> look
>> >> >> nice, but ultimately you may end up wasting my time and yours when I
>> >> >> come
>> >> >> and revert your change.
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Thu, Aug 4, 2016 at 7:52 AM, Robinson, Paul via llvm-dev
>> >> >> <llvm-dev at lists.llvm.org> wrote:
>> >> >>
>> >> >> I've heard from another group within Sony that they had "a number of
>> >> >> problems" with VS2015 update 2, and strongly recommend going
>> straight
>> >> >> to
>> >> >> update 3.  My immediate team has initiated a request but it hasn't
>> gone
>> >> >> through yet.
>> >> >>
>> >> >> --paulr
>> >> >>
>> >> >>
>> >> >>
>> >> >> From: James Molloy [mailto:james at jamesmolloy.co.uk]
>> >> >> Sent: Wednesday, August 03, 2016 1:54 AM
>> >> >> To: Nico Weber; Robinson, Paul
>> >> >> Cc: llvm-dev; cfe-dev at lists.llvm.org
>> >> >> Subject: Re: [cfe-dev] [llvm-dev] Revisiting our informal policy to
>> >> >> support two versions of MSVC
>> >> >>
>> >> >>
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >>
>> >> >>
>> >> >> This sounds like a decent idea to me. However we use 2013 for all
>> our
>> >> >> windows builds at the moment and it will take around 2 weeks to
>> upgrade
>> >> >> the
>> >> >> installations on our cluster. We're pushing this hard to get it done
>> >> >> soon so
>> >> >> we don't get caught short, but a grace period would be much
>> >> >> appreciated.
>> >> >>
>> >> >>
>> >> >>
>> >> >> Cheers,
>> >> >>
>> >> >>
>> >> >>
>> >> >> James
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Tue, 2 Aug 2016 at 21:24 Nico Weber via cfe-dev
>> >> >> <cfe-dev at lists.llvm.org> wrote:
>> >> >>
>> >> >> On Tue, Aug 2, 2016 at 3:49 PM, Robinson, Paul via cfe-dev
>> >> >> <cfe-dev at lists.llvm.org> wrote:
>> >> >>
>> >> >> For my project, timing is everything.  We (and I could easily
>> imagine,
>> >> >>
>> >> >> for many downstream projects) lead time is important.
>> >> >>
>> >> >>
>> >> >>
>> >> >> In Chromium land, we've so far been able to use the same compiler we
>> >> >> use
>> >> >> to build Chrome to build clang. Currently that's MSVS2015 update 2,
>> and
>> >> >> it
>> >> >> took quite a while to update from 2013 to 2015 due bugs in 2015 and
>> >> >> whatnot.
>> >> >> So I agree that it's useful to support older MSVS versions for some
>> >> >> time.
>> >> >> For this reason, requiring update 3 would be inconvenient for us,
>> but
>> >> >> 2015u2
>> >> >> would be no problem by now. It would've been a problem if 2015 had
>> been
>> >> >> required shortly after it was released.
>> >> >>
>> >> >>
>> >> >>
>> >> >> Nico
>> >> >>
>> >> >> _______________________________________________
>> >> >> 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
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160901/97a762d0/attachment.html>


More information about the llvm-dev mailing list