similar to: [LLVMdev] Clang's approach to anonymous struct pointer parameters

Hi Rick, this is a bug in Clang's LLVM-IR code generator: http://llvm.org/bugs/show_bug.cgi?id=14920 Best, Florian On Sunday, January 20, 2013 01:57:37 Rick Mann wrote: > For the following code: > > struct XBeePacket; > > typedef void (*CompletionProc)(XBeePacket* inPacket, void* inParam2); > > struct > XBeePacket > { >

I have used libdispatch (on FreeBSD) from JIT'd code without any issues, so I think your bug is elsewhere. David On 30 Jan 2013, at 07:43, Rick Mann wrote: > My host app calls runFunction() on my JITed code. It, in turn, calls a C function ("decode()") in the host app that then calls dispatch_async(). The runFunction() call returns as expected, but the block passed to

My host app calls runFunction() on my JITed code. It, in turn, calls a C function ("decode()") in the host app that then calls dispatch_async(). The runFunction() call returns as expected, but the block passed to dispatch_async() never gets called. The async block is supposed to call a function pointer callback that was passed in to decode(). Everything is being called on the main

Hi all, I am trying to build a global control flow graph at machine code level. Essentially, I need the handles to the MachineFunction's corresponding to every call site inside a MachineFunction in order to get the handles to MachineBasicBlock's with return statements inside the callee. Currently, the codegen module processes one MachineFunction at a time and hence I can't find a way

Hi Abhishek, On Sunday, July 29, 2012 18:32:11 AbhishekR wrote: > It seems like I may have to modify the way MachineFunction is instantiated in MachineFunctionAnalysis. Instead of doing it per Function, it may have to be done for the entire Module by instantiating MachineFunction objects for every Function inside the Module. This might require major changes to the PassManager framework as well.

On Wed July 11 2012 11:50:01 Chandler Carruth wrote: > - What else did I miss? > > > Things that are totally out of scope: pass registration, the current pass order and structure, the fundamental interface of mapping from a pass to an analysis, etc. This is really about pass management and scheduling. > Hi Chandler, I understand why the pass registration and the pass

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Sean Silva > Subject: Re: [LLVMdev] What would cause instructions to NOT make it into the module? > It is a pass that can be run like any other pass. See createVerifierPass(). You can also just call verifyModule() with the appropriate parameters; it's defined in

Greetings folks! In working on a new optimization pass (splitting cold regions into separate functions based on branch probabilities) I've run into some limitations of the current pass manager infrastructure. After chatting about this with Nick, it seems that there are some pretty systematic weaknesses of the current design and implementation (but not with the fundamental concepts or

Hi all! I know this is quite offtopic, but I found nothing in google nor in the net-snmp mailing list, and I know there''s a lot of people here graphing with snmp+rrdtool. I installed net-snmp 5.1.2-6.1 in Debian to produce graphs for some ethernet interfaces. It seems it''s not reporting correct values for them. Here''s my snmpd.conf (very simple) and the output from the