[llvm-dev] [cfe-dev] Revisiting our informal policy to support two versions of MSVC
Aaron Ballman via llvm-dev
llvm-dev at lists.llvm.org
Thu Sep 1 10:09:49 PDT 2016
On Wed, Aug 31, 2016 at 7:07 PM, Reid Kleckner via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> 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.
I agree, I think it's time. I think a month is reasonable, assuming
that it doesn't cause massive problems for anyone (which it doesn't
sound like it will).
> 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.
I also agree with this.
~Aaron
>
> 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
>
More information about the llvm-dev
mailing list