similar to: [LLVMdev] va_arg on x86-64

Hi everyone, I'm interested in variadic functions and how llvm handles them. I discovered that the Clang frontend is doing a great job at lowering the va_arg (precisely __builtin_va_arg) function into target dependent code. I have also seen the va_arg function that exist at IR level. I found some information about va_arg (IR one) that currently does not support all platform. But since 2009,

Provide a full-fledged example of working variable arguments on X86_64, since it's easily the most popular platform. Cc: Reid Kleckner <rnk at google.com> Signed-off-by: Ramkumar Ramachandra <artagnon at gmail.com> --- docs/LangRef.rst | 44 ++++++++++++++++++++++++++++++-------------- 1 file changed, 30 insertions(+), 14 deletions(-) diff --git a/docs/LangRef.rst

Hi everyone, I'm interested in variadic functions and how llvm handles them. I discovered that the Clang frontend is doing a great job at lowering the va_arg (precisely __builtin_va_arg) function into target dependent code. I have also seen the va_arg function that exist at IR level. I found some information about va_arg (IR one) that currently does not support all platform. But since 2009,

Hi, So the Variable Argument Handling Intrinsics section of the LangRef (http://llvm.org/docs/LangRef.html#variable-argument-handling-intrinsics) lists an example that segfaults. Try the following on x86_64: -- 8< -- define i32 @test(i32 %X, ...) { ; Initialize variable argument processing %ap = alloca i8* %ap2 = bitcast i8** %ap to i8* call void @llvm.va_start(i8* %ap2) ; Read a

Neal, FYI, my group has added a flag to llvm-gcc for emitting the va_arg instruction (instead of lowering in the front-end), and we also have an implementation of the VAARG instruction for X86-64. (which is currently not implemented in the LLVM backend). Both of these things will be sent upstream to LLVM soon, pending some more testing and review. If you are dire need of these features now, I

I would like to be able to instrument va_arg, but when I generate a bc file for a test case using: llvm-gcc -O3 -emit-llvm vararg.c -c -o vararg.bc I do not see va_arg. Instead, it seems the args are accessed through %struct.__va_list_tag, which makes things a bit trickier to instrument. Is there a way to force llvm-gcc to use va_arg? Perhaps there is some documentation about va_list_tag or

Hi folk, I'm writing a set of small C code to verify whether my pass handle some instruction correctly. One of the instruction I want to test is "va_arg", but compiling my variadic function does not generate any va_arg instruction. Is va_arg deprecated? Will va_arg instruction ever be generated by any front-end? The source code and llvm instructions are appended as follows. the

Hi, The problem is resolved. I try the svn trunk, llc work fine to generate the MIPS assembly. Also, I try both llvm-gcc and clang, they work fine at my current project, though I will use clang to instead of llvm-gcc. Thanks, everyone. Regards, Leo 2011/8/16 Akira Hatanaka <ahatanak at gmail.com>: > You might want to use clang instead of llvm-gcc: I think there are > still bugs

On Mon, Aug 15, 2011 at 2:18 AM, Leo Chen. <leo.q.chen at gmail.com> wrote: > Hi, > > I am using llc (llvm 2.9) to generate the MIPS assembly I would suggest trying trunk; there have been a lot of improvements recently to the MIPS backend. -Eli > but failed > when compile any codes > with va_start()/va_end()/va_arg(). > > Here is the minimal step to reproduce the

Hi all, I'm having some trouble with inline asm expressions, more specifically how to create the right FunctionType for a given constraint set. So far it has worked well for inputs, but not for outputs. The inline asm support in this language (which is D, LLVMDC[1]) is through asm *statements*. I never have inline asm *expressions*, and outputs are always via memory. I D my test looks like

Hi, I am using llc (llvm 2.9) to generate the MIPS assembly, but failed when compile any codes with va_start()/va_end()/va_arg(). Here is the minimal step to reproduce the failure: llvm-gcc-4.2 -emit-llvm hello.c -c -o hello.bc llc -march=mips hello.bc -o hello.s llc show this erroe message: LLVM ERROR: Cannot select: 0xa1873a0: ch = vaend 0xa187290:1, 0xa185ae0, 0xa187318 [ID=38] 0xa185ae0:

On Aug 15, 2011, at 9:42 AM, Eli Friedman wrote: > On Mon, Aug 15, 2011 at 2:18 AM, Leo Chen. <leo.q.chen at gmail.com> wrote: >> Hi, >> >> I am using llc (llvm 2.9) to generate the MIPS assembly > > I would suggest trying trunk; there have been a lot of improvements > recently to the MIPS backend. > I agree. Also, make sure you're using a MIPS

Hi Richard, I tried latest 3.7.1 release, the clang has same build failure and don’t know __builtin_ms_va_list at all. I compared the llvm trunk with 3.7.1 and find the trunk has a VA commit from Davis which is not included in the 3.7.1 release. So, I guess I need to directly build the latest trunk instead of the 3.7.1 release. (why 3.7.1 release doesn’t include this patch?) commit

target datalayout = "e-m:x-p:32:32-i64:64-f80:32-n8:16:32-a:0:32-S32" target triple = "i686-pc-windows-msvc" declare void @llvm.va_start(i8**) declare void @llvm.va_end(i8**) define i64 @foo(...) { %va = alloca i8*, i32 16 ; 4 words should be enough? call void @llvm.va_start(i8** %va) %x = va_arg i8** %va, i64 call void @llvm.va_end(i8** %va) ret i64 %x }

Could you file a bug? On Wed, Feb 27, 2013 at 2:47 AM, Stavropoulos Nikos < n.stavropoulos at think-silicon.com> wrote: > i have this code > > typedef long long L; > typedef integer I; > void test2(auto L p0, auto L p1, auto L p2, auto L p4, ...) > { > va_list select; > > va_start (select, p4); > > report( va_arg(select,L) ); > report(

i have this code typedef long long L; typedef integer I; void test2(auto L p0, auto L p1, auto L p2, auto L p4, ...) { va_list select; va_start (select, p4); report( va_arg(select,L) ); report( va_arg(select,I) ); report( va_arg(select,L) );

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

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

I check the Mips backend for the following C code fragment compile result. It seems not correct. Is it my misunderstand or it's a bug. //ch8_3.cpp #include <stdarg.h> int sum_i(int amount, ...) { int i = 0; int val = 0; int sum = 0; va_list vl; va_start(vl, amount); for (i = 0; i < amount; i++) { val = va_arg(vl, int); sum += val; } va_end(vl);

Which part of the generated code do you think is not correct? Could you be more specific? I compiled this program with clang and ran it on a mips board. It returns the expected result (21). On Tue, Feb 19, 2013 at 4:15 AM, Jonathan <gamma_chen at yahoo.com.tw> wrote: > I check the Mips backend for the following C code fragment compile result. > It seems not correct. Is it my