similar to: [LLVMdev] Do we still need LLVM_HAS_INITIALIZER_LISTS?

On Mon, Feb 16, 2015 at 10:30 PM, David Majnemer <david.majnemer at gmail.com> wrote: > > > On Mon, Feb 16, 2015 at 3:56 PM, Justin Bogner <mail at justinbogner.com> > wrote: >> >> Currently, LLVM_HAS_INITIALIZER_LISTS is set based on >> >> __has_feature(cxx_generalized_initializers) && !defined(_MSC_VER) >> >> Based on the

Your install dir has a whitespace. Have you tried quoting? e.g. <LLVMInstallDir>"C:\Program Files (x86)\LLVM"</LLVMInstallDir> Best regards, Rafael Auler On Mon, Sep 29, 2014 at 7:38 PM, Eric Mader <emader at gmx.us> wrote: > I changed tooset-vs2013.props to this: > > <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" >

I replaced all instances of "$(Platform)" with "x64" for the x64 .props file and it still fails, so it looks like that guess was wrong as well. Regards, Eric On 9/29/14, 2:11 PM, Eric Mader wrote: > Quoting doesn't seem to make a difference. Strangely, the Win32 > toolset seems to work. (Where "work" means that clang runs and > produces a bunch of

Open the file toolset-vs2013.props and you'll understand what's happening and where the path is set. It tries to fetch the LLVM installation path from the Windows registry. Just fix this (maybe editing your registry or editing the .props file, whatever suits you best). On Mon, Sep 29, 2014 at 5:33 PM, Eric Mader <emader at gmx.us> wrote: > I copied the x64 toolsets by hand and

I have moved onto the next phase and committed r229185, which makes VS2013 our minimum version. I will revert if issues arise, and we can rinse and repeat as necessary. Once it sticks for a bit I’ll update the docs too. -Chris > On Feb 9, 2015, at 10:07 AM, Chris Bieneman <beanz at apple.com> wrote: > > I agree with Aaron, this should not be a blocker because the workaround is

Hi, I have attached a small patch from r192263 that I am using to add LLVM into the toolchain for VS2013. Is someone able to review this and (if all good) submit to the source tree? Changes are all local to llvm/tools/msbuild/ and account for VS2013 requiring the files to be named toolset.props / .targets, rather than the longer name in the previous versions. Cheers, Joshua Samuel

I'm using Windows 8.1, and every time I run check-clang, I eventually end up with a bunch of hung processes. Generally this is an instance of clang.exe, a bunch of instances of FileCheck.exe, and occasionally an llc.exe and an opt.exe. Inside, the processes are all hung inside of calls to WriteFile() attempting to write to stdout. I notice some of the tests fail with output indicating that

Hello, Today we hit another VS 2013 breakage < http://lab.llvm.org:8011/builders/sanitizer-windows/builds/26666/steps/run%20tests/logs/stdio> which results us having to alter LLVM. While we have no documented policy of supporting two version of MSVC, we do have an informal agreement that we should support the last two versions. I suggest that we alter our informal policy to the following:

On Tue, Oct 8, 2013 at 7:13 PM, Josh Samuel <JSamuel at iress.com.au> wrote: > I have attached a small patch from r192263 that I am using to add LLVM into > the toolchain for VS2013. > > Is someone able to review this and (if all good) submit to the source tree? I don't have VS2013 to verify this with, but the patch looks good and since it works for you, I've committed

On Wed, Oct 8, 2014 at 12:17 PM, Greg Bedwell <gregbedwell at gmail.com> wrote: > Hi, > > To follow up from Paul last week: > >> I'm expecting to have our internal builds switched over later this >> week. Our investigations have shown no problems. > > We've now updated our internal builds from 2012.4 (cl.exe 17.0.61030) to > 2013.3 (cl.exe

On Mon, Feb 9, 2015 at 8:36 AM, Greg Bedwell <gregbedwell at gmail.com> wrote: > We've just encountered an issue with ninja and VS2013 when using versions of > CMake prior to 2.8.12.1. This isn't a combination that we typically use so > we've not run into it previously in our own builds. It isn't specifically > tied to upgrading the minimum version as it's a

VS2013 support is dropped in about 1 week from now :) On Thu, Oct 6, 2016 at 11:37 PM Mueller-Roemer, Johannes Sebastian < Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote: > Visual Studio up to and including VS2013 implements > std::chrono::high_resolution_clock in an absolutely unusable manner (it is > a very low resolution clock…) [1]. Also, division is implemented

I think it's been a little over a year since we bumped the minimum VS version to 2013. Are we planning to do the same for 2015? Update 2 is releasing soon, which is stable enough at least to ship Chromium <https://randomascii.wordpress.com/2016/03/24/compiler-bugs-found-when-porting-chromium-to-vc-2015/> . Language wise, 2015 comes with a lot of new C++ features. The most interesting

> -----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

Hi, It looks like I forgot to "svn add" the 2 targets files, and a typo appeared in the CMakelists.txt Fixes attached. "Works on my machine guarantee" ;-) Note - to actually compile the MSVC v120 header files will take a fair bit more work - there are a number of type traits not implemented by clang, that are breaking my MFC builds at the moment. (And a few compiler

Hi all, We're considering using std::chrono more heavily in lldb. However, A quick search of the llvm, clang, and lld codebases shos almost zero usage of chrono. I wanted to see if this was for technical reasons (eg some compiler doesn't support it well) or simply because nobody has needed it yet. If it's the former then I'd like to be aware of the issues so we don't fall into

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

We inject a typedef for size_t here: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/Sema.cpp?revision=218230&view=markup#l206 The typedef type is determined by calling getSizeType(). SizeType is (relevantly) calculated in two places: X86_64 http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?revision=218666&view=markup#l3512 X86_32

The bot has been failing its CMake step for a while now. Probably fallout from renaming Msf to MSF. Can somebody get this straightened out? It's one of the bots that run VS2013 AFAICT which makes it useful to me. Thanks, --paulr

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