similar to: [LLVMdev] PSA: clang-cl can self host now!

Done: http://llvm.org/viewvc/llvm-project/cfe/branches/release_36/docs/ReleaseNotes.rst?view=markup#l113 We've been technically able to self-host for a some time, but now it's simple as 'CC=clang-cl CXX=clang-cl cmake'. =D On Wed, Feb 25, 2015 at 3:00 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > Nice. This should probably go to on the release notes :-)

Even without a concrete use case, I agree that it's absolutely imperative for the standard to require this of a conforming implementation. It's going to be the source of so many problems otherwise On Fri, May 12, 2017 at 9:14 AM Hal Finkel <hfinkel at anl.gov> wrote: > > On 05/12/2017 11:00 AM, Scott Smith wrote: > > On Fri, May 12, 2017 at 12:52 AM, Bryce Lelbach

I'm trying to figure out how to get, from CMake, the architecture of the platform that I'm compiling LLVM for. If I'm building LLVM on x86, I want x86. On x64 I want x86_64. On arm arm. etc. The best I can figure out so far is that I should use LLVM_HOST_TRIPLE, and extract the first component of this. At least if my understanding is correct, I should have the following behavior:

llvm-lit is already put into <output-tree>/bin by CMake. There is a CMake target called `llvm-lit` that will generate the <output-dir>/bin/llvm-lit script. If you built only a few specific llvm targets such as FileCheck, etc then you may need to run this lit target manually. If you just run "ninja" for example, or "ninja check-llvm", it's automatically

Even if it were under llvm, that doesn't mean it would have to be part of ninja check-all. Currently we have lldb/test and lldb/unittests, what about a third lldb/dbgtests? Then you could run it as ninja check-dbgtest. Although now that I think about it, we would want it to be able to invoke clang-cl directly, so I guess that does necessitate it *not* being under llvm. On Thu, Sep 7, 2017

llvm-profdata is part of llvm though. It’s perfectly fine for something in clang to depend on something in llvm. However, clang and lld are two independent llvm subprojects, neither of which can depend on each other. Generally speaking, from a layering perspective, if A depends on B and C, but B and C are independent, that should be reflected in the structure. For example, in CMake we will need

It looks like the bots are still red? — Adrian > On Nov 10, 2017, at 3:14 PM, Zachary Turner <zturner at google.com> wrote: > > Wasn't quite fixed, but it got a lot further this time. This time there was still an issue in the test_debuginfo.pl <http://test_debuginfo.pl/> script regarding a hardcoded path to the llgdb.py script. I think I never encountered this locally

Since this is causing all of our internal CI to back up, could you please revert your two changes, so we can make sure that they were actually responsible, and can work on a fix for this? Let me know how we can help investigate this. -- adrian > On Nov 13, 2017, at 3:25 PM, Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The first build where a test fails with

On the other hand this file hasn't changed recently, but I have no way to test this as it uses the LLDB code path, which only runs on OSX. On Mon, Nov 13, 2017 at 3:19 PM Zachary Turner <zturner at google.com> wrote: > I might be missing something, but this doesn't look like me? > > >

Yea I also just found it. Try adding this code in the bottom of debuginfo-tests/lit.cfg.py lit.util.usePlatformSdkOnDarwin(config, lit_config) On Mon, Nov 13, 2017 at 4:38 PM Adrian Prantl <aprantl at apple.com> wrote: > Ha! Found it. *Somebody* is setting an SDKROOT variable in the > environment. Can you find the code that would do this? > > — adrian > > > On Nov

Yes I can reproduce this locally. It looks like we are not passing an -isysroot (pointing to the SDK) to clang but it isn’t clear what lit magic would expand this. -- adrian > On Nov 13, 2017, at 3:30 PM, Zachary Turner <zturner at google.com> wrote: > > Yea I'm preparing a revert right now. Does it happen for you when you run debuginfo-tests locally? > > On Mon, Nov

On Fri, May 12, 2017 at 12:52 AM, Bryce Lelbach <balelbach at lbl.gov> wrote: > * I am concerned that nested parallel algorithms will prove to be a > big implementation burden for GPU and accelerator architectures. > Can't they fall back on serial execution? I thought the executor is a hint, not a requirement (certainly the standard doesn't say it has to execute on

Great! It's close to the end of the day, so I'll submit tomorrow to make sure everything has a chance to go fully green again to ensure I get failure emails if it breaks. On Mon, Nov 13, 2017 at 4:43 PM Adrian Prantl <aprantl at apple.com> wrote: > I can confirm that that fixes the issue! > > — adrian > > > On Nov 13, 2017, at 4:38 PM, Zachary Turner <zturner

From the CI side moving this stuff around is a huge undertaking. We include this repo in every build, they will all need to be fixed and verified. It is a lot of work on our side. Is there a plan for both system to work side-by-side as we migrate jobs? Talking to Mike today, we estimated a week of work to migrate and verify, plus residual failures for the next month. Regarding your

What is the status of debuginfo-tests? Is it actively supported? How do you run it? It doesn't appear to be based on lit, any particular reason? Why is it its own repo instead of being part of llvm repo? I'd like improve this to support CodeView and PDB, such that it would only run on Windows and only if a suitable debugger was found (probably WinDbg). WinDbg supports a

Hi Zackary, Did you see my followup to you cfe-commits rollback: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20171120/210212.html I think you can just remove the change to cfe/trunk/test/CMakeLists.txt and it should work just fine. hth... don On Tue, Nov 21, 2017 at 12:00 PM Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Just an update, > > At

It's hard to say. By definition it appears undefined (in the sense that the TS literally does not define it), but on the other hand it is a TS and this issue would (hopefully) come up and be specified before it made it to standardization. Supporting recursive parallel calls certainly seems like desirable behavior, so from my point of view it would be nice to make sure it works. Not sure if

I sorta enjoy debugging stuff like this, so if you don't mind, I'll dig into it once I get a chance -- traveling so, my access is a bit sketchy right now. I'll see if I can grab the logs and let you know if I find anything interesting. On Tue, Nov 21, 2017 at 7:04 PM, Zachary Turner <zturner at google.com> wrote: > That change was added specifically to workaround a failure

I don’t personally develop on Mac (i use Windows), but I have an analogous setup there where i use ninja to build and Visual Studio for editing, debugging, etc. What i do, and I assume it will be the same or very similar for Xcode, is to run cmake twice, once with Ninja, and once with VS (Xcode for you), from separate directories. I build with the ninja one (“ninja clang” on command line), and I

On Fri, Nov 3, 2017 at 9:34 PM Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > By adding in a different suite, you mean the lld part? I mean > theoretically, but that would be pretty awkward, because the idea behind > the lld requirement is that we want to make debuginfo-tests work with > clang-cl and CodeView debug info, and for this lld is a hard