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

[Nico Weber via cfe-dev]

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

> I don't see how the policy of supporting 2 versions is related to that
> difficulty though. Whether we support 1 versions or 2 versions, 1 version
> is still going to be deprecated every time a new version is released. So
> this burden on upgrading buildbots doesn't seem to be much different.
>
> As long as chromium compiler version is not tied to llvm compiler version
> (and if it did, that would be a chromium decision not an llvm one) this is
> always going to be a problem whether llvm supports newest compiler or
> newest 2 compilers


I think in general the world is trying to update to new toolchains, it just
takes a while. With LLVM's old policy, Chromium always updated faster than
LLVM so far.


>
> On Thu, Sep 1, 2016 at 12:09 PM Nico Weber <thakis at chromium.org> wrote:
>
>> 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/cfe-dev/attachments/20160901/2292a8f5/attachment.html>