similar to: [LLVMdev] __builtin_va_list different on targets

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

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>

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

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.

Zig tests using Debug build of 5.0.1rc2 hit this bug: https://bugs.llvm.org/show_bug.cgi?id=34452 I suppose the fix has not been backported to 5.0.1. So I created a Release build of 5.0.1rc2 and all zig tests pass, with the following patches: * Patches to LLD: commit a206ef34bbbc46017e471063a4a1832c1ddafb0a Author: Andrew Kelley <superjoe30 at gmail.com> Date: Fri Dec 1 12:11:55 2017

Hi Richard, Thank you for the info. I build my code in Ubuntu-64bits with simply commands: “clang X64.c”, then run “./a.out” to see the output. If I replace my va_list, va_start, va_arg va_end with __builtin_ms_va_list, __builtin_ms_va_start, __builtin_ms_va_arg, __builtin_ms_va_end, my code will build fail in Ubuntu with below message. Do you suggest I should build it in windows and not in

I am using the Clang c++ API. I have a blocking issue because the builtin __builtin_va_list clang isn't defined. Here is the error: ..lib/clang/3.2/include/stdarg.h:30:9: error: unknown type name '__builtin_va_list'; did you mean '__builtin_va_list'? typedef __builtin_va_list va_list; >From what I've read, this builtin is target dependent. This builtin is not defined

For the variadic function error with AMD64 abi and windows calling convention on 64bits x86, I find it has been tracked in Bug 20847 (https://llvm.org/bugs/show_bug.cgi?id=20847) (http://reviews.llvm.org/D1622#inline-9345). Do we still plan to fix it? You know, I meet exactly same va_arg mistake with llvm3.7 when I enable the Uefi firmware (http://www.uefi.org/) build with clang. The ms_abi is

Hello everyone, I made a quick patch to clang/llvm to introduce an "apple_abi" function attribute (https://github.com/aguinet/llvm-project/commit/c4905ded3afb3182435df30e527955031cb0d098), to be able to compile functions for the Apple ARM64 ABI when targeting other ARM64 OSes (e.g. Linux). This can be seen as the Apple version of the already existing "ms_abi" attribute. In

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 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

I'd like to parse a C++ header file (say, math.h) with the Clang bindings for Python. (Yes, I know math.h is technically a C header, but for my purposes I want to pretend that it is C++.) For some reason, Clang is able to parse the file as C, but not as C++. Here is an example session: >>> import clang.cindex >>> idx = clang.cindex.Index.create() >>> tu =

Hi, I've tagged the 5.0.1-rc2 release, go ahead and start testing and report your results. -Tom

Answering my own question: On Fri, Oct 18, 2013 at 8:51 PM, Elliott Slaughter < elliottslaughter at gmail.com> wrote: > I'd like to parse a C++ header file (say, math.h) with the Clang bindings > for Python. (Yes, I know math.h is technically a C header, but for my > purposes I want to pretend that it is C++.) For some reason, Clang is able > to parse the file as C, but not

On Mon, 11 Sep 2006, [UTF-8] Rafael Esp?ndola wrote: > I am trying to build llvm-gcc4 on a amd64. I had to add the attached > patch to get the build system to select the correct library. Now the Applied. > build fails while compiling a code that has __builtin_va_copy. The > attached test.i fails with: > > cc1: ../../trunk/gcc/llvm-convert.cpp:443: llvm::Value* >

Hi, I am writing a pass which is supposed to ignore library functions. Is there a way to distinguish functions declared and defined by a developer from non-local functions (library functions)? Thanks. George -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110523/650c7fa4/attachment.html>

I am trying to build llvm-gcc4 on a amd64. I had to add the attached patch to get the build system to select the correct library. Now the build fails while compiling a code that has __builtin_va_copy. The attached test.i fails with: cc1: ../../trunk/gcc/llvm-convert.cpp:443: llvm::Value* TreeToLLVM::Emit(tree_node*, llvm::Value*): Assertion `(isAggregateType(((exp)->common.type)) == (DestLoc

Is FLAC a variable bit rate format when streamed? If so, how can it be truly lossless? -- Dennis Brunnenmeyer Director of Engineering CEDAR RIDGE SYSTEMS 15019 Rattlesnake Road Grass Valley, CA 95945-8710 Office: 1 (530) 477-9015 Mobile: 1 (530) 320-9025 eMail: dennisb /at/ chronometrics /dot/ com http://www.chronometrics.com/crs/index.html <http://www.chronometrics.com/crs/index.html>