similar to: [LLVMdev] [RFC] New ToolsSupport library for stuff that only tools need

There is no real technical requirement for this. Currently we work around the signal handlers by building with ENABLE_CRASH_OVERRIDES=NO, and carrying along the command line parsing code and ToolOutputFile isn’t really a big drain. This seemed to me like the cleanest way to accomplish a goal of mine. The goal I have is to be able to build an LLVM dylib and llc/opt/etc from the same CMake

+1 to this. I'd slightly prefer a separate library (though moving the code vs not moving the code I'm relatively apathetic about), but just because I hate conditional compilation. -eric On Thu Oct 30 2014 at 5:55:59 PM Juergen Ributzka <juergen at apple.com> wrote: > I am mostly impartial to the two proposed solutions (separate library or > conditional compilation of the

I was thinking of moving the files into a Tools subdirectory of Support, and having a new library generated from that. Does that mesh with what you’d like to see? I’ve gotten wrapped into a nasty internal bug hunt, so I probably won’t have patches until next week. I will also probably need to ask Eric for help with the autoconf side of things because my familiarity with autoconf ends at “run

I think for the main goal of cleaning up the Mac-specific hack, a CrashRecovery library would work equally well. Juergen is more familiar with the WebKit side of things, so he may be aware of something I’m not thinking of. Chandler, does splitting out a CrashRecovery library instead seem sane? Other than code organization and naming, the general idea of splitting out a CrashRecovery library

I would have preferred the library to be moved out of the “Support” folder and have its own top-level library and include folder. Just my 2 cents. > On Nov 6, 2014, at 2:12 PM, Chris Bieneman <beanz at apple.com> wrote: > > So, I decided to try and start small. My idea here was create a ToolsSupport library, and move one small, but important function into the new library to shake

> On Nov 6, 2014, at 3:00 PM, Reid Kleckner <rnk at google.com> wrote: > > On Thu, Nov 6, 2014 at 2:42 PM, Juergen Ributzka <juergen at apple.com <mailto:juergen at apple.com>> wrote: > I would have preferred the library to be moved out of the “Support” folder and have its own top-level library and include folder. > > +1, you will need to do this if you want

Here is my limited perspective on this topic: 1. I would like to see some of the code in LLVM's ADT and Support libraries available for reuse in other projects. This also has some potential for being useful to Clang -- one could imagine a world where Clang directly linked the ADT & Support libraries, but used the compiler itself via a clear dynamic-library vended API (which would be

I'm encountering a few problems in my migration that I haven't yet figured out. `getOrInsertFunction` is generating a SEGFAULT at FunctionType::isValidArgumentType(llvm::Type*).  I'm calling it as:     generic_ptr_ = llvm::PointerType::get( llvm::Type::getInt8Ty(context), 0 );     f_natural_int = llvm::IntegerType::get(context, 64);     module->getOrInsertFunction(        

Hello, So the current JIT will be superseded by the MCJIT completely and no further development should be expected for the current JIT? In any case, I am definitely interested in submitting a patch if you could help me by sending me in the right direction, since I really want this working. I managed to reproduce this behavior in LLVM 3.0 by modifying llc to read my .bc file and try to JIT the

Galina and Takumi, Are we ready to update the minimum required version to 2.8.12.2? -Chris > On Feb 12, 2015, at 2:35 PM, Chris Bieneman <beanz at apple.com> wrote: > > Chandler's feedback was that we should go to 2.8.12.2 instead of 3.0 because of Ubuntu's LTS release. > > -Chris > > > > On Feb 12, 2015, at 11:29 AM, Galina Kistanova <gkistanova

Sadly I really can’t help you debug the home-brew build, it is a good ways outside my expertise. If you want to try building from source using the guide here: http://llvm.org/docs/GettingStarted.html#getting-started-quickly-a-summary <http://llvm.org/docs/GettingStarted.html#getting-started-quickly-a-summary> I’d be more helpful. As it is, the patch you proposed doesn’t seem to make it

+Galina, and Takumi This was a very short lived change :-). Looks like we have some bots that need to be updated. -Chris > On Feb 9, 2015, at 12:02 PM, Chandler Carruth <chandlerc at google.com> wrote: > > > On Mon, Feb 9, 2015 at 11:48 AM, Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote: > Apple doesn’t ship CMake publicly. Our internal

The behavior here is consistent with setting SDKROOT in the environment to an OS X SDK. -Chris > On Sep 22, 2015, at 2:28 PM, Alex Wang <aw1621107 at gmail.com> wrote: > > Logs + commands added to the earlier gist. > > Only thing different from a plain trunk build is adding -Wl,-v and -Wl,-t to the > iossim link flags. > >> On Sep 22, 2015, at 5:17 PM, Chris

I'm with Takumi, and prefer to go on a safe route. Takumi, unless I'm missing something you were checking cmake 3.x with LLVM. How does it look like? Did you discover any problem? Thanks Galina On Mon, Feb 9, 2015 at 4:28 PM, NAKAMURA Takumi <geek4civic at gmail.com> wrote: > I missed the context. We may stand on 2.8.12.2 at first. > > I will update my cmake from

> On 2015-Jun-03, at 12:57, Chris Bieneman <beanz at apple.com> wrote: > > >> On Jun 2, 2015, at 6:29 PM, Richard Smith <richard at metafoo.co.uk> wrote: >> >> On 2 Jun 2015 2:04 pm, "Jonathan Roelofs" <jonathan at codesourcery.com> wrote: >> > >> > >> > >> > On 6/2/15 2:38 PM, Duncan P. N. Exon Smith

> On Dec 10, 2014, at 4:22 PM, Eric Christopher <echristo at gmail.com> wrote: > > > > On Wed Dec 10 2014 at 3:57:25 PM Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote: > llvm-dev, > > In my ongoing saga to improve LLVM for embedded use, we would like to support stripping out unused intrinsics based on the LLVM targets actually

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

On Dec 23, 2014, at 10:28 AM, Chris Bieneman <beanz at apple.com> wrote: >>> It should be straight-forward to have something like LLVMInitializeX86Target/RegisterTargetMachine install the intrinsics into a registry. >> >> I tried doing that a few years ago. It’s not nearly as easy as it sounds because we’ve got hardcoded references to various target intrinsics scattered

It seems the crash of llvm/clang build on aarch64 Debian has been fixed by r220941. Thanks, -Jiangning 2014-11-05 8:45 GMT+08:00 Jiangning Liu <liujiangning1 at gmail.com>: > The versions I'm using right now are > > * gcc: (Debian/Linaro 4.9.1-14) 4.9.1 > * libstdc++: libstdc++.so.6.0.20 > > Thanks, > -Jiangning > > 2014-11-05 4:46 GMT+08:00 Chris Bieneman

On Mon, Dec 22, 2014 at 12:55 PM, Chris Bieneman <beanz at apple.com> wrote: > > On Dec 22, 2014, at 12:02 PM, Chandler Carruth <chandlerc at google.com> > wrote: > > > On Fri, Dec 19, 2014 at 3:39 PM, Chris Bieneman <beanz at apple.com> wrote: > >> More diffs to enjoy. >> >> I’ve updated my tablegen patches to work with the