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

I guess what I'm getting at, is why do we even need to support 2 toolchains
with LLVM *at all*?  Why can't we just always upgrade to the newest one
unless there are serious issues with it?

There used to be two reasons that I'm aware of:

1) Licensing.  Community used to be Express, and Express used to be limited
in functionality.  But this is no longer the case.  Community is fine for
anyone to use, even corporations, for free, as long as it is for an open
source project.  IANAL, but it says it in Section 1.b.1 here
<https://www.visualstudio.com/support/legal/mt171547>.

2) Library toolchain mismatches.  It used to be that in order to link
against a library, it had to be compiled with the same toolchain.  So
someone whose application was built with VS 2012 couldn't link against LLVM
built with VS 2013, they would have to build LLVM themselves with VS2012,
so dropping support for 2012 would harm them.

But beginning with Visual Studio 2015, because of the UCRT, this is no
longer the case.  All versions of the CRT will be forward compatible.

So if we're going to upgrade to VS 2015, why not also just upgrade to VS 15
as soon as possible?  Once VS 2015 is the minimum, it doesn't seem like we
should worry too much about upgrading compiler versions anymore (aside from
the effort to actually do it and make sure it works and the compiler bugs
and issues are known about).

On Thu, Sep 1, 2016 at 12:24 PM Nico Weber <thakis at chromium.org> wrote:
> 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/llvm-dev/attachments/20160901/90edd67b/attachment.html>

> On Sep 1, 2016, at 12:35 PM, Zachary Turner via cfe-dev <cfe-dev at
lists.llvm.org> wrote:
> 
> I guess what I'm getting at, is why do we even need to support 2
toolchains with LLVM *at all*?  Why can't we just always upgrade to the
newest one unless there are serious issues with it?
> 
> There used to be two reasons that I'm aware of:
> 
> 1) Licensing.  Community used to be Express, and Express used to be limited
in functionality.  But this is no longer the case.  Community is fine for anyone
to use, even corporations, for free, as long as it is for an open source
project.  IANAL, but it says it in Section 1.b.1 here
<https://www.visualstudio.com/support/legal/mt171547>.
> 
> 2) Library toolchain mismatches.  It used to be that in order to link
against a library, it had to be compiled with the same toolchain.  So someone
whose application was built with VS 2012 couldn't link against LLVM built
with VS 2013, they would have to build LLVM themselves with VS2012, so dropping
support for 2012 would harm them.
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.

— 
Mehdi


> 
> But beginning with Visual Studio 2015, because of the UCRT, this is no
longer the case.  All versions of the CRT will be forward compatible.
> 
> So if we're going to upgrade to VS 2015, why not also just upgrade to
VS 15 as soon as possible?  Once VS 2015 is the minimum, it doesn't seem
like we should worry too much about upgrading compiler versions anymore (aside
from the effort to actually do it and make sure it works and the compiler bugs
and issues are known about).
> 
> On Thu, Sep 1, 2016 at 12:24 PM Nico Weber <thakis at chromium.org
<mailto:thakis at chromium.org>> wrote:
> On Thu, Sep 1, 2016 at 3:16 PM, Zachary Turner <zturner at google.com
<mailto: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
<mailto:thakis at chromium.org>> wrote:
> On Thu, Sep 1, 2016 at 3:03 PM, Zachary Turner <zturner at google.com
<mailto: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 <mailto:cfe-dev at lists.llvm.org>> wrote:
> On Thu, Sep 1, 2016 at 2:08 PM, Nico Weber <thakis at chromium.org
<mailto:thakis at chromium.org>> wrote:
> > On Thu, Sep 1, 2016 at 1:30 PM, Aaron Ballman <aaron at
aaronballman.com <mailto: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 <mailto: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 <mailto: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
<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 <mailto: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 <mailto: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
<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
<mailto: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 <mailto: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 <mailto: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 <mailto:cfe-dev at
lists.llvm.org>
> >> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> LLVM Developers mailing list
> >> >> llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
> >> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > cfe-dev mailing list
> >> > cfe-dev at lists.llvm.org <mailto:cfe-dev at
lists.llvm.org>
> >> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
> >> >
> >
> >
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
<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/47e645ff/attachment.html>

Community is fine for anyone to use, even corporations, for free, as long as it
is for an open source project.  IANAL, but it says it in Section 1.b.1
here<https://www.visualstudio.com/support/legal/mt171547>.

While LLVM per se is an open-source project, the toolchain I actually deliver to
my licensees is not.  IANAL either but I believe "Community" is not a
solution for us, for that reason.
--paulr

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Zachary
Turner via llvm-dev
Sent: Thursday, September 01, 2016 12:36 PM
To: Nico Weber
Cc: 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 guess what I'm getting at, is why do we even need to support 2 toolchains
with LLVM *at all*?  Why can't we just always upgrade to the newest one
unless there are serious issues with it?

There used to be two reasons that I'm aware of:

1) Licensing.  Community used to be Express, and Express used to be limited in
functionality.  But this is no longer the case.  Community is fine for anyone to
use, even corporations, for free, as long as it is for an open source project. 
IANAL, but it says it in Section 1.b.1
here<https://www.visualstudio.com/support/legal/mt171547>.

2) Library toolchain mismatches.  It used to be that in order to link against a
library, it had to be compiled with the same toolchain.  So someone whose
application was built with VS 2012 couldn't link against LLVM built with VS
2013, they would have to build LLVM themselves with VS2012, so dropping support
for 2012 would harm them.

But beginning with Visual Studio 2015, because of the UCRT, this is no longer
the case.  All versions of the CRT will be forward compatible.

So if we're going to upgrade to VS 2015, why not also just upgrade to VS 15
as soon as possible?  Once VS 2015 is the minimum, it doesn't seem like we
should worry too much about upgrading compiler versions anymore (aside from the
effort to actually do it and make sure it works and the compiler bugs and issues
are known about).

On Thu, Sep 1, 2016 at 12:24 PM Nico Weber <thakis at
chromium.org<mailto:thakis at chromium.org>> wrote:
On Thu, Sep 1, 2016 at 3:16 PM, Zachary Turner <zturner at
google.com<mailto: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<mailto:thakis at chromium.org>> wrote:
On Thu, Sep 1, 2016 at 3:03 PM, Zachary Turner <zturner at
google.com<mailto: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<mailto:cfe-dev at lists.llvm.org>> wrote:
On Thu, Sep 1, 2016 at 2:08 PM, Nico Weber <thakis at
chromium.org<mailto:thakis at chromium.org>>
wrote:
> On Thu, Sep 1, 2016 at 1:30 PM, Aaron Ballman <aaron at
aaronballman.com<mailto: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<mailto: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<mailto: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<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<mailto: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<mailto: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<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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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/0d3b596d/attachment-0001.html>

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