search for: __builtin_va_list

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

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

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

...s 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: > > 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*...

...e() >>> tu = idx.parse('/usr/include/math.h', ['-x', 'c++-header']) >>> c = tu.cursor >>> for d in c.get_children(): ... print d.kind, d.spelling ... CursorKind.TYPEDEF_DECL __int128_t CursorKind.TYPEDEF_DECL __uint128_t CursorKind.TYPEDEF_DECL __builtin_va_list CursorKind.UNEXPOSED_DECL >>> print len(tu.diagnostics) 0 Now that list clearly does not represent the contents of math.h. However, as you can see, I don't get an error, and the list of diagnostics is empty. When I use C mode, I instead get the list of functions I'm expecting to...

...s/stdarg.h b/c_headers/stdarg.h index d603d353..101426ff 100644 --- a/c_headers/stdarg.h +++ b/c_headers/stdarg.h @@ -26,14 +26,10 @@ #ifndef __STDARG_H #define __STDARG_H -/* zig: added because macos _va_list.h was duplicately defining va_list - */ #ifndef _VA_LIST -#ifndef _VA_LIST_T typedef __builtin_va_list va_list; #define _VA_LIST #endif -#endif #define va_start(ap, param) __builtin_va_start(ap, param) #define va_end(ap) __builtin_va_end(ap) #define va_arg(ap, type) __builtin_va_arg(ap, type) @@ -50,9 +46,6 @@ typedef __builtin_va_list va_list; #ifndef __GNUC_VA_LIST #define __GNU...

...9;/usr/include/math.h', ['-x', 'c++-header']) > >>> c = tu.cursor > >>> for d in c.get_children(): > ... print d.kind, d.spelling > ... > CursorKind.TYPEDEF_DECL __int128_t > CursorKind.TYPEDEF_DECL __uint128_t > CursorKind.TYPEDEF_DECL __builtin_va_list > CursorKind.UNEXPOSED_DECL > It would seem that the contents on the entire module are hidden inside this UNEXPOSED_DECL. I'd be interesting in knowing why that is, but for now at least I seem to have solved my problem. > >>> print len(tu.diagnostics) > 0 > > Now t...

...you suggest I should build it in windows and not in Linux? Or did I miss any build option here? Appreciate if you could let me know the correct build steps. jshi19 at jshi19-Intel:/mnt/disk3$ clang X64.c X64.c:12:2: error: unknown type name '__builtin_ms_va_list'; did you mean '__builtin_va_list'? __builtin_ms_va_list Marker; ^~~~~~~~~~~~~~~~~~~~ __builtin_va_list note: '__builtin_va_list' declared here X64.c:15:2: error: use of unknown builtin '__builtin_ms_va_start' [-Wimplicit-function-declaration] __builtin_ms_va_start (Marker...

...;/usr/include/math.h', ['-x', 'c++-header']) > >>> c = tu.cursor > >>> for d in c.get_children(): > ... print d.kind, d.spelling > ... > CursorKind.TYPEDEF_DECL __int128_t > CursorKind.TYPEDEF_DECL __uint128_t > CursorKind.TYPEDEF_DECL __builtin_va_list > CursorKind.UNEXPOSED_DECL > > It would seem that the contents on the entire module are hidden inside this UNEXPOSED_DECL. I'd be interesting in knowing why that is, but for now at least I seem to have solved my problem. I am not sure why that is, but cfe-dev at cs.uiuc.edu is the...

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

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

...you suggest I should build it in windows and not in Linux? Or did I miss any build option here? Appreciate if you could let me know the correct build steps. jshi19 at jshi19-Intel:/mnt/disk3$ clang X64.c X64.c:12:2: error: unknown type name '__builtin_ms_va_list'; did you mean '__builtin_va_list'? __builtin_ms_va_list Marker; ^~~~~~~~~~~~~~~~~~~~ __builtin_va_list note: '__builtin_va_list' declared here X64.c:15:2: error: use of unknown builtin '__builtin_ms_va_start' [-Wimplicit-function-declaration] __builtin_ms_va_start (Marker...

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

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

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

...100644 --- a/xen/include/xen/stdarg.h +++ b/xen/include/xen/stdarg.h @@ -1,9 +1,7 @@ #ifndef __XEN_STDARG_H__ #define __XEN_STDARG_H__ -#if defined(__OpenBSD__) -# include "/usr/include/stdarg.h" -#elif defined (__NetBSD__) +#if defined(__OpenBSD__) || defined(__NetBSD__) typedef __builtin_va_list va_list; # define va_start(ap, last) __builtin_stdarg_start((ap), (last)) # define va_end(ap) __builtin_va_end(ap)

..._tag' |-TypedefDecl 0x8e42408 <<invalid sloc>> <invalid sloc> implicit __builtin_ms_va_list 'char *' | `-PointerType 0x8e423d0 'char *' | `-BuiltinType 0x8e41b40 'char' |-TypedefDecl 0x8e42728 <<invalid sloc>> <invalid sloc> implicit __builtin_va_list 'struct __va_list_tag [1]' | `-ConstantArrayType 0x8e426d0 'struct __va_list_tag [1]' 1 | `-RecordType 0x8e424f0 'struct __va_list_tag' | `-CXXRecord 0x8e42458 '__va_list_tag' `-NamespaceDecl 0x8e42778 <example.hpp:5:1, line:7:1> line:5:11 ns `-VarDecl...

...lt;<invalid sloc>> <invalid sloc> implicit __uint128_t 'unsigned __int128' |-TypedefDecl 0xd6c3c8 <<invalid sloc>> <invalid sloc> implicit __builtin_ms_va_list 'char *' `-TypedefDecl 0xd6c590 <<invalid sloc>> <invalid sloc> implicit __builtin_va_list 'struct __va_list_tag [1]' ========================================================= LLVM IR ========================================================= target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-pc-linux" !llvm.dbg.cu = !{!0} !l...

...lt;<invalid sloc>> <invalid sloc> implicit __uint128_t 'unsigned __int128' |-TypedefDecl 0xd6c3c8 <<invalid sloc>> <invalid sloc> implicit __builtin_ms_va_list 'char *' `-TypedefDecl 0xd6c590 <<invalid sloc>> <invalid sloc> implicit __builtin_va_list 'struct __va_list_tag [1]' ========================================================= LLVM IR ========================================================= target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-pc-linux" !llvm.dbg.cu<http://...

...lt;<invalid sloc>> <invalid sloc> implicit __uint128_t 'unsigned __int128' |-TypedefDecl 0xd6c3c8 <<invalid sloc>> <invalid sloc> implicit __builtin_ms_va_list 'char *' `-TypedefDecl 0xd6c590 <<invalid sloc>> <invalid sloc> implicit __builtin_va_list 'struct __va_list_tag [1]' ========================================================= LLVM IR ========================================================= target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-pc-linux" !llvm.dbg.cu<http://...