search for: va_lists

Hi, Chris Lattner wrote: > All the non-vastart calls can be anywhere. va_end in particular codegens > to a noop on all targets llvm currently supports, fwiw. > Things go well, except for the following (pathological?) C program: int va_double_sum(int count,...){ int i,sum=0; va_list ap; va_start(ap,count); for(i=0;i<count;i++){ sum+=va_arg(ap,int); } va_end(ap);

Hi everyone, Currently, when declaring a va_list in llvm, one only needs to do: %ap = alloca i8 * (Reference : llvm/docs/LangRef.html#int_varargs) This is OK for x86 and PPC/Darwin ABI because a va_list in these architectures is just a pointer to the stack. The va_start intrinsic just initializes where the pointer points at in the stack. I do not know how the other backends operate, but I

On 4/2/07, Nicolas Geoffray <nicolas.geoffray at lip6.fr> wrote: > Hi everyone, > > Currently, when declaring a va_list in llvm, one only needs to do: > > %ap = alloca i8 * (Reference : llvm/docs/LangRef.html#int_varargs) This example is x86 specific. alpha allocas an {sbyte*, int} (and does so in llvm-gcc). What the type of the alloca to use is requires the frontend to

On Wednesday, 11 October 2017 17:23:45 CEST Richard W.M. Jones wrote: > +static int > +mexp_vprintf (mexp_h *h, int password, const char *fs, va_list args) > { > - va_list args; > char *msg; > int len; > size_t n; > ssize_t r; > char *p; > > - va_start (args, fs); > len = vasprintf (&msg, fs, args); > - va_end (args); Due to the

stubdom: add v?errx? and v?warnx? functions Signed-off-by: Samuel Thibault <samuel.thibault@eu.citrix.com> diff -r 14a9a1629590 extras/mini-os/include/posix/err.h --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/extras/mini-os/include/posix/err.h Wed Aug 27 10:29:36 2008 +0100 @@ -0,0 +1,15 @@ +#ifndef _POSIX_ERR_H +#define _POSIX_ERR_H + +#include <stdarg.h> + +void err(int eval,

Hi Andrew, Andrew Lenharth wrote: > On 4/2/07, Nicolas Geoffray <nicolas.geoffray at lip6.fr> wrote: > >> Hi everyone, >> >> Currently, when declaring a va_list in llvm, one only needs to do: >> >> %ap = alloca i8 * (Reference : llvm/docs/LangRef.html#int_varargs) >> > > This example is x86 specific. alpha allocas an {sbyte*, int}

On 9 August 2017 at 19:38, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 8/9/2017 9:11 AM, Alex Bradbury via llvm-dev wrote: >> >> Option 3: Teach va_arg to handle aggregates >> * In this option, va_arg might reasonably be expected to handle a >> struct, >> but would not be expected to have detailed ABI-specific knowledge. e.g. >> it

Both of these functions are using strlen() to create return value. Cheers, Scott Rankin *** /openbsd-compat/bsd-snprintf.c.orig Thu Oct 18 13:57:51 2001 --- /openbsd-compat/bsd-snprintf.c Thu Oct 18 13:58:26 2001 *************** *** 632,638 **** #endif /* !defined(HAVE_SNPRINTF) || !defined(HAVE_VSNPRINTF) */ #ifndef HAVE_VSNPRINTF ! int vsnprintf(char *str, size_t count, const char *fmt,

Full_Name: Albrecht Gebhardt Version: 0.99.0 OS: alpha, osf4.0 Submission from: (NULL) (143.205.180.40) Both DEC cc and gcc complain (osf4.0, alpha) about applying an unary operator (!) to a non scalar type (va_list arg) in printutils.c I'm not sure if I understood what was intended by "!arg" (see below), but with this patch I at least was able to compile. (and R runs now, but I

On Tue, 3 Oct 2006, Bram Adams wrote: >> You'd have to change it to something like: >> void foo(int X, ...) { >> P = va_start(); >> bar(X, P); >> } >> >> void bar(int X, valist P) { >> use(P); >> } > > Can the other va_...-intrinsics be used in bar as were the "P = > va_start" in bar? The va_start probably is

Hi everyone, I'm implementing varags handling for PPC32 with the ELF ABI. It is largely more complicated than the Macho ABI or x86 because it manipulates a struct instead of a direct pointer in the stack. You can find the layout of the va_list struct at the end of this mail. A VAARG call requires a lot of computation. Typically the C code for va_arg(ap, int) is: int va_arg_gpr(ap_list

This might shed some light on the va_list problem reported previously. -d David Hesprich wrote: > > On Wed, 8 Mar 2000, Damien Miller wrote: > > > > log.c: In function `fatal': > > > log.c:17: `__builtin_va_alist' undeclared (first use in this function) > > > > A few people have reported this - it looks like a gcc vs native cc > > problem.

Hi, Op 3-okt-06, om 20:48 heeft Chris Lattner het volgende geschreven: > You'd have to change it to something like: > > void foo(int X, ...) { > P = va_start(); > bar(X, P); > } > > void bar(int X, valist P) { > use(P); > } Can the other va_...-intrinsics be used in bar as were the "P = va_start" in bar? The va_start probably is unnecessary

# The future of the va_arg instruction ## Summary LLVM IR currently defines a va_arg instruction, which can be used to access a vararg. Few Clang targets make use of it, and it has a number of limitations. This RFC hopes to promote discussion on its future - how 'smart' should va_arg be? Should we be aiming to transition all targets and LLVM frontends to using it? ## Background on va_arg

As this symbol is never exported from the server, don't call it "nbdkit_vfprintf". Also move it to a new file to make forthcoming changes easier. Fixes commit 1c230358462c349533062eda9e4072054fda0e21. --- server/Makefile.am | 1 + server/internal.h | 14 +++++----- server/log.c | 24 ----------------- server/vfprintf.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++

I've had fairly good sucecss with the portable OpenSSH 2.1.1p1 on Irix 6.2. There's one major nit, and a few things that configure got wrong. I'm kinda deep in real work at the moment, so I don't have time to delve heavily, but since configure specifically asked for feedback on this port, I'm obliging. The biggest problem I've run into so far is in the builtin PRNG

Hi, I'm trying to write some forward constant propagation of sprintf and friends, and I need a way to construct a (build) va_list from the IR of a variadic function so that I can evaluate it at build time. I can't find a standard way of doing this. -- --- Shawn Landden +1 360 389 3001 (SMS preferred)

Apart from removing a slightly misleading comment, this small refactoring makes subsequent commits simpler but otherwise doesn't change anything. --- server/internal.h | 3 +++ server/log.c | 15 ++++++++++----- 2 files changed, 13 insertions(+), 5 deletions(-) diff --git a/server/internal.h b/server/internal.h index e5c7f514..b43798ff 100644 --- a/server/internal.h +++

Hi, Op 5-okt-06, om 16:05 heeft Ryan Brown het volgende geschreven: > I don't know if that's valid but what about something like this: > int va_double_sum(int count,...){ > /*declare va_list for each original va_start*/ > /*llvm.va_start for each va_list*/ > /*call extracted_sum(count,va_list1, va_list2, ...)*/ > } That should work, I think, ... Op 5-okt-06, om

Hi all, I''m working on the EventLog#read method for the pure Ruby version of win32-eventlog, but I''m stuck on the get_description private method. Here are the problems: * I don''t think I''m advancing the EVENTLOGRECORD properly between iterations. Take a look at the end of the "while dwread > 0" loop. I get some records, but not all of them.