similar to: [LLVMdev] buildbot failure

On Dec 12, 2011, at 2:12 PM, Tony Linthicum wrote: > Hi folks, > > I just committed a new backend for the Hexagon processor. After committing, I was able to successfully check out, build and test with the new changes. The x86_64 build on the buildbot is failing, however. Here's the build error: > > llvm[2]: Linking Debug+Asserts executable llvm-mc >

On 12/12/2011 4:28 PM, Jakob Stoklund Olesen wrote: > > On Dec 12, 2011, at 2:12 PM, Tony Linthicum wrote: > >> Hi folks, >> >> I just committed a new backend for the Hexagon processor. After >> committing, I was able to successfully check out, build and test with >> the new changes. The x86_64 build on the buildbot is failing, >> however.

On Dec 12, 2011, at 2:41 PM, Eric Christopher wrote: > > On Dec 12, 2011, at 2:36 PM, Tony Linthicum wrote: > >> On 12/12/2011 4:28 PM, Jakob Stoklund Olesen wrote: >>> >>> >>> On Dec 12, 2011, at 2:12 PM, Tony Linthicum wrote: >>> >>>> Hi folks, >>>> >>>> I just committed a new backend for the Hexagon

On Dec 12, 2011, at 2:51 PM, Tony Linthicum wrote: > On 12/12/2011 4:49 PM, Eric Christopher wrote: >> >> >> On Dec 12, 2011, at 2:41 PM, Eric Christopher wrote: >> >>> >>> On Dec 12, 2011, at 2:36 PM, Tony Linthicum wrote: >>> >>>> On 12/12/2011 4:28 PM, Jakob Stoklund Olesen wrote: >>>>> >>>>>

On Dec 12, 2011, at 2:36 PM, Tony Linthicum wrote: > On 12/12/2011 4:28 PM, Jakob Stoklund Olesen wrote: >> >> >> On Dec 12, 2011, at 2:12 PM, Tony Linthicum wrote: >> >>> Hi folks, >>> >>> I just committed a new backend for the Hexagon processor. After committing, I was able to successfully check out, build and test with the new changes.

On 12/12/2011 4:49 PM, Eric Christopher wrote: > > On Dec 12, 2011, at 2:41 PM, Eric Christopher wrote: > >> >> On Dec 12, 2011, at 2:36 PM, Tony Linthicum wrote: >> >>> On 12/12/2011 4:28 PM, Jakob Stoklund Olesen wrote: >>>> >>>> On Dec 12, 2011, at 2:12 PM, Tony Linthicum wrote: >>>> >>>>> Hi folks,

I'm hitting this. Is there ETA for the fix? Evan On Dec 12, 2011, at 2:58 PM, Daniel Dunbar wrote: > > On Dec 12, 2011, at 2:51 PM, Tony Linthicum wrote: > >> On 12/12/2011 4:49 PM, Eric Christopher wrote: >>> >>> >>> On Dec 12, 2011, at 2:41 PM, Eric Christopher wrote: >>> >>>> >>>> On Dec 12, 2011, at 2:36

I thought it was already fixed, so no. I hate to say this, but can you try first: touch $LLVM_SRC_ROOT/LLVMBuild.txt and a make? If that doesn't work, try a make clean? I'll try and find a real fix tomorrow. - Daniel On Dec 12, 2011, at 5:44 PM, Evan Cheng wrote: > I'm hitting this. Is there ETA for the fix? > > Evan > > On Dec 12, 2011, at 2:58 PM, Daniel

Hi, when building llvm as a shared library LLVMInitializeNativeTarget and co. (located in llvm/Support/TargetSelect) will not get exported as symbol into the shared library, because they are static inline. Since they are functions defined in the C API no one else inside LLVM calls them, which results in them not being exported. This is, of course, no problem for C programs using the C API,

Hi Frédéric and LLVM, I managed to finally come back to this after quite a while. Frédéric, thank you very much for the pointer to your work; it’s saving me a lot of time! Unfortunately, I am running into one issue that my knowledge isn’t complete enough to solve on my own yet. The description of D6771 reads, "It requires a few preliminary patches like landing D6243 and adding a

I've managed to get 10.0.0 working now.. there were a couple things I had to adjust. The Kaleidoscope example had me doing this before creating the object file: llvm::InitializeAllTargetInfos(); llvm::InitializeAllTargets(); llvm::InitializeAllTargetMCs(); llvm::InitializeAllAsmParsers(); llvm::InitializeAllAsmPrinters(); It turns out I can get away with just this, since I'm not (yet)

OK, fine -- an example of MCJIT that sets up for PTX JIT would also be helpful. On Dec 6, 2013, at 12:32 PM, Eli Bendersky <eliben at google.com> wrote: > > You'll have to switch to MCJIT for this purpose. Legacy JIT doesn't emit PTX. > > Eli -- Larry Gritz lg at larrygritz.com -------------- next part -------------- An HTML attachment was scrubbed... URL:

Dear all I am trying to get the size of an LLVM pointer type. getPrimitiveSizeInBits() returns 0 for it and the documentation for isSized() suggest to use TargetData. I figured out from Kaleidoscope example that one can get a pointer to TagetData object through the execution engine but it seems to be an overkill. What is the right way to do it? Best regards, Victor -------------- next part

For those targets supported by LLVM, you can get their TargetData by creating TargetMachine first (take X86 as example): ==== BEGIN CODE SNIPPET ==== const std::string TripleStr = "i686-unknown-linux"; // hard coded for example const std::string FeatureStr = ""; // hard coded for example std::string Err; const Target* T; TargetMachine* TM = NULL; const

There is no MCJIT support for PTX at the moment (mainly because PTX does not have a binary format, and is not machine code per se). To generate PTX at run-time, you just set up a standard codegen pass manager like you would like an off-line compiler. The output will be a string buffer that contains the PTX, which you can load into the CUDA runtime. As for determining if PTX support is compiled

Mehdi, Teresa, Not sure if this is caused by one of your recent commits, or by someone else's, please excuse me if that's unrelated to your work... http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/542/steps/check-llvm%20asan/logs/stdio ==26383==ERROR: AddressSanitizer: initialization-order-fiasco on address 0x000002ef41d8 at pc 0x0000009d1aa5 bp 0x7ffd0cd72b50 sp

Ah, that's helpful. I knew that I'd need to end up with PTX as text, not a true binary, but I would have figured that it would come out of MCJIT. Thanks for helping to steer me away from the wrong trail. OK, one more question: Can anybody clarify the pros and cons of generating the PTX through the standard LLVM distro, versus using the "libnvvm" that comes with the Cuda SDK?

When using ORC JIT, I'm having trouble with external function resolution (that is, of a function defined in the app, with C linkage). I add a declaration for the function to my IR, and when I use MCJIT, it finds it and all is well, But when I use ORC JIT (I *think* correctly, at least it closely matches what I see in the tutorial), I get an LLVM error, "Program used external function

You may want to try adding this code (copy/pasted from llc.cpp): // Initialize targets first, so that --version shows registered targets. InitializeAllTargets(); InitializeAllTargetMCs(); InitializeAllAsmPrinters(); InitializeAllAsmParsers(); // Initialize codegen and IR passes used by llc so that the -print-after, // -print-before, and -stop-after options work. PassRegistry

llvm-dev, Thanks so much in advance for any help, tips, or advice you may be able to offer me. I'm going to try to avoid the big-picture description of the project I'm working on, and only talk about the parts that I have trouble with / currently need to implement. -- I've been starting by taking the source code from the "llvm-mc" tool, and working that down into a