similar to: Revisiting our informal policy to support two versions of MSVC

-----Original Message----- > From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of Aaron > Ballman via cfe-dev > Sent: Tuesday, August 02, 2016 12:06 PM > To: David Majnemer > Cc: llvm-dev; cfe-dev > Subject: Re: [cfe-dev] [llvm-dev] Revisiting our informal policy to > support two versions of MSVC > > On Tue, Aug 2, 2016 at 1:24 PM, David Majnemer via

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

Hi all, Firstly sorry I'm a bit late responding on this one. Internally to ARM we build LLVM for Windows. Our current build cluster has only VS2013 installed and as a result of this thread we've been working on getting VS2015 installed. This involves a certain amount of IT-wrangling as the cluster we use is company-wide. There have been some hiccups regarding licensing of MSVC

Apart from the obvious licencing issues, each time I have moved from one version of VC++ to another, the big problem I have had is not specifically the ABI at the register passing, stack organisation level, but rather the implementation details of the Standard C++ libraries, and in particular the STL containers. While the compiler team puts considerable effort into maintaining the ABI, the C++

I'll need to dig up the references for that... but I'm pretty sure the universal CRT that debuted in MSVC 2015 only covers the C parts, and not the C++ parts. On 9/7/2016 4:28 PM, Zachary Turner wrote: > It's worth pointing out that from 2015 and on, they claim to support > full forwards compatibility of the standard libraries, so this should > (in theory) never be an

I can't say I'm excited to support MSVC 2013 for another month, but I'm more concerned about the burden on other developers. People I talked to at the SF bay area social last Thursday were really excited to drop 2013 support. I guess I'll leave my buildbots on another month and see how it goes. On Thu, Sep 8, 2016 at 7:03 AM, Robinson, Paul via llvm-dev < llvm-dev at

Hi, As I understand it the specific issue we're seeing is related to what Martin described. But due to numerous bugs found when mixing objects compiled with different versions of MSVC in the past, we now are shy of doing it even if it seems to work superficially - that's no guarantee bugs won't be found down the line. We'd much prefer to stay within the realms of what Microsoft

Hi Mehdi, Yes, all on track and thank you all for your kind patience! Cheers, James On Fri, 7 Oct 2016 at 20:13, Mehdi Amini <mehdi.amini at apple.com> wrote: > Hi James, > > Are you still on track for pulling the plug on MSVC 2013 at the end next > week? > > As another data point, other than new features or build failures, I just > had to debug (with the help of

Thank you both, we appreciate it a lot! On Thu, 8 Sep 2016 at 16:37, Aaron Ballman via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Thu, Sep 8, 2016 at 11:24 AM, Reid Kleckner via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > I can't say I'm excited to support MSVC 2013 for another month, but I'm > more > > concerned about the burden on

Hi, “clang-x64-ninja-win7” was switched to VS2015. It is red now due to a few PDB tests and one sanitizer test. Failing Tests (10): LLVM :: DebugInfo/PDB/DIA/pdbdump-flags.test LLVM :: DebugInfo/PDB/DIA/pdbdump-linenumbers.test LLVM :: DebugInfo/PDB/DIA/pdbdump-symbol-format.test LLVM :: tools/llvm-pdbdump/class-layout.test LLVM :: tools/llvm-pdbdump/enum-layout.test

Hi, If there is no blocker (James?), we should be able to move on, so I filed as a starter: https://reviews.llvm.org/D25710 <https://reviews.llvm.org/D25710>: [Doc] Drop MSVC2013 support — Mehdi > On Oct 12, 2016, at 4:03 PM, Reid Kleckner <rnk at google.com> wrote: > > I migrated the sanitizer-windows builder to VS 2015, and it went green here: >

We can try to print a better error message here, but it looks like regardless someone will need physical access to the bot to determine what the problem is with DIA. On Wed, Oct 19, 2016 at 8:51 AM Reid Kleckner <rnk at google.com> wrote: > I filed https://llvm.org/bugs/show_bug.cgi?id=30736 to get that fixed. > > On Wed, Oct 19, 2016 at 3:52 AM, Briltz, Denis <Denis.Briltz at

The new error message is: llvm-pdbdump: DIA Error: An unknown error has occurred. HRESULT: 0x800700C1: Calling NoRegCoCreate which is more or less what I expected. The specific HResult is kind of interesting, it maps to "msdia140.dll is not a valid Win32 application". I don't know if this means that it can't find the DLL, or that it did find the DLL and it's corrupt. Is

As mentioned upthread, we're still on update 2 for various reasons. 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

FWIW, no objections from me, after all I proposed this 3 months ago :) Probably Aaron Ballman should comment though since the primary objection last time was his. On Fri, Jul 29, 2016 at 2:00 PM Sean Silva <chisophugis at gmail.com> wrote: > On Fri, Jul 29, 2016 at 1:23 PM, Robinson, Paul via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> There are certainly

> -----Original Message----- > From: aaron.ballman at gmail.com [mailto:aaron.ballman at gmail.com] On Behalf > Of Aaron Ballman > Sent: Friday, July 29, 2016 2:19 PM > To: Zachary Turner > Cc: Sean Silva; Robinson, Paul; Piotr Padlewski; llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] Upgrading to MSVC 2015 > > There are not that many people making commits to

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

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

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

There are not that many people making commits to working around MSVC 2013 as I think are claimed (there are certainly a lot of commits for working around MSVC in general, however). A quick search through the code base shows there are 8 instances where we've worked around MSVC 2013 issues (there may be more that someone worked around in an ad hoc manner and did not mark). We definitely had *a