similar to: [LLVMdev] Any plan for WHOPR on LLVM?

Dear all, AFAIK, ARM EHABI is not ready for both asm and obj emitter. Some people including me what to implement them. My question is, to avoid duplicate effort, does someone take charge of this part? or does anyone is already implementing this currently? BTW, any suggestion on this effort? I'm very appreciated! Thanks in advance! -- Best regards, Wen-Han Gu (Nowar) -------------- next

On May 22, 2011, at 8:49 PM, Wenhan Gu wrote: > I know __builtin_va_list is target-specific, and > ARM has typedef void* __builtin_va_list; > X86 has typedef char* __builtin_va_list; > > > It seems they can be treated as the same prototype,i.e.. void*, at the header level. > What I want to ask is: > > If I write a program use "typedef void*

Thanks for your answer very much. I wonder for what reason does ARM use *void ** but X86 use *char ** ? Seems ARM uses void * since its spec said that. But X86? I cannot find any reason or spec to specify why X86 uses char *, not void * directly? Could anyone give me some hints? Thanks a lot. 2011/5/23 John McCall <rjmccall at apple.com> > On May 22, 2011, at 8:49 PM, Wenhan Gu wrote:

OK. Thank you. What I want to do is: Fix source code in-place, then feed it to compiler normally. I assume I can fix source code in-place using clang::SourceManager, but I cannot find the appropriate API. Now I know that way is infeasible. Thanks again. 2011/5/5 Joshua Warner <joshuawarner32 at gmail.com> > Wen-Han, > > It sounds like there are two problems here: first is

Forgot to CC the list. On Wed, May 4, 2011 at 10:16 PM, Joshua Warner <joshuawarner32 at gmail.com>wrote: > Wen-Han, > > It sounds like there are two problems here: first is detecting when free is > not properly called, and figuring out where to insert the call - which seems > like an intractable problem by iteself. Second is a reversible translation > from C to LLVM IR.

Dear Renato and Anton, Big thanks to your help. Those references are very helpful! BTW, After I applying this patch from Logan Chien, I pass some examples on ARM assembly emission. It seems good to me. http://llvm.org/bugs/show_bug.cgi?id=7187#attach_9161 For object file emission, The first thing is making MC generate correct .ARM.exidx and .ARM.extab. I will keep tracing that. Thanks!

I've been digging into COMDAT with regular LTO, specifically in the context of the LLVM gold plugin. The GCC WHOPR documentation specifies that the linker will resolve all COMDAT groups to the IR-provided definitions, if available. Additionally it specifies that "When the WPA phase produces the definition of the COMDAT symbol in a new object file, that definition should not be in a COMDAT

LLVMers, Its been 2 months since our last release, so its time to start thinking about LLVM 2.1. Ideally, we like to do releases every 3 months, but the last release was an unusually long 6 month release cycle. For this release, I'm planning to do things slightly differently. I'm proposing the following schedule for our 2.1 release: August 27th - I'll do a comparision of

Dear all, I cannot find the answer of this question. We all know LLVM IR is portable, but it uses ILP32 and record the target layout within the IR. target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64 :64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64" target triple = "x86_64-linux-gnu" It seems it already assigned

Dear all, I heard a different way to solve it. $ apt-get install libc6-dev-amd64 Maybe this can help? 2010/12/30 Anton Korobeynikov <anton at korobeynikov.info> > Hello > > > Thanks for the tip. My PS3 workstationn is installed a 32-bit OS. I will > Please carefully read the readme.llvm file in the llvm-gcc source > directory. > At least it will give some hints how

Hello all, I wanna build a static linked executable using llvm. But I failed. My question is Can we use -static using llvm? Thanks for any response. Below is details ======== First I use $ clang++ test.cc `llvm-config --cxxflags --ldflags --libs` I works as usual. But if I use $ clang++ test.cc `llvm-config --cxxflags --ldflags --libs` -static It yells lots of undefined reference, like

Thanks very much for all of your answer. I was confused by definition of 'portable' by my own thinking. Now I Correct that. (ILP32 is in another project, It's my typo. Thanks) So let me make a conclusion about this. LLVM IR can be a portable language, just depending on our front-end configuration or origin language limits. Did I mistake that? Thank a lot all of you. 2010/12/22

Dear LLVMers, Here is the current, tentative schedule for LLVM 1.5: 1. We are hoping to have all relevant features and bug fixes into mainline CVS by Friday of this week. For those of you with commit access, please plan to have all of your changes for LLVM 1.5 committed by 9 am (CST) this Friday. If you need more time, please email the list. 2. On Friday, I will be making the 1.5 release

On Wed, Feb 19, 2020 at 03:00:11PM +0100, Csaba Henk wrote: > Hi, > > I scribbled a simple guestfs based program called guestfs-xfer with > following synopsis: > > Usage: guest-xfer [options] [op] [diskimage] > > op = [ls|cat|write] > > options: > -d, --guestdevice DEV guest device > --blocksize BS blocksize [default:

Hi all, in this case: ... int* p = ... int* q = p; ... How can I know that data-flow from p to q, i.e., which LLVM pass of header files could I use? Thank you all. -- Best regards, Wen-Han -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110430/a9164c60/attachment.html>

(repost the reply using my personal account -- previous reply to the list got hold up) On Thu, Dec 25, 2014 at 11:55 PM, Adve, Vikram Sadanand <vadve at illinois.edu> wrote: > Diego, Teresa, David, > > Sorry for my delayed reply; I left for vacation right after sending my message about this. > > Diego, it wasn't explicit from your message whether LLVM LTO can handle

Hi, I scribbled a simple guestfs based program called guestfs-xfer with following synopsis: Usage: guest-xfer [options] [op] [diskimage] op = [ls|cat|write] options: -d, --guestdevice DEV guest device --blocksize BS blocksize [default: 1048576] -o, --offset OFF offset [default: 0] So eg. `cat /dev/urandom | guest-xfer -d /dev/sda

Hi all, I know __builtin_va_list is target-specific, and ARM has typedef void* __builtin_va_list; X86 has typedef char* __builtin_va_list; It seems they can be treated as the same prototype,i.e.. void*, at the header level. What I want to ask is: If I write a program use "typedef *void** __builtin_va_list" on X86, and run it. Would I face any problem on run-time? I think it won't

Dear all, I'm a beginner in LLVM field. If any rudeness, I feel sorry to that. I have checked-out the source and built successfully. Now I want to use it, so I write a simple code. // context.cpp #include "llvm/LLVMContext.h" int main() { llvm::LLVMContext& context = llvm::getGlobalContext(); return 0; } $ clang++ `llvm-config --cxxflags --ldflags --libs` context.cpp But

The problem seems to be that whenever Samba becomes LMB for a subnet, Dave sends a series of broadcast netbios-dgm packets that cause nmbd to segfault. This is only a problem with Dave 2.5.2, Dave 2.5.1 works fine. It occurs consistently, with Samba 2.0.7 and 2.2.0 on linux (Redhat on x86), NetBSD (on mips) and OpenBSD (x86). That pretty much rules out operating system or hardware failure. ;)