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

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


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/fb7d1de8/attachment.html>

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>

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
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/4e831f0a/attachment.html>