[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 11:08:16 PDT 2016


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).


> 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.


>
> ~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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160901/b452ef95/attachment.html>


More information about the llvm-dev mailing list