Displaying 20 results from an estimated 20000 matches similar to: "[LLVMdev] Seemingly ambiguous parameter lists"
2003 Aug 26
0
[LLVMdev] Seemingly ambiguous parameter lists
Dear Chris,
I had a second question which is probably a dumb question, but here
goes. I'm just wondering how a function that has all varargs knows what to
do. I'm only familiar with the C style of varargs. In that case you
generally used one or more fixed parameters that told you how to interpret
the rest. Like the format string in printf, for example. I suppose the
function
2004 Jan 21
3
[LLVMdev] Re: Bytecode Format
I'm the guy who is working on the LLVM bytecode documentation. The document
I have at present just supports the bytecodes my code generator processes,
though, which is far from all of them. As I get farther along with my code
generator I expect I'll get to the point where everything kind of fits
together for me and I can finish it up. In the meantime, people are welcome
to what I have
2006 Oct 25
2
[LLVMdev] Some basic questions about LLVM version 1.8 bytecode format
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I generated LLVM bytecode for a "hello world!" program just to get the
basic bytecode structure. I have
2004 Jan 21
0
[LLVMdev] Re: Bytecode Format
On Wed, Jan 21, 2004 at 08:25:23AM -0800, Robert Mykland wrote:
> I'm the guy who is working on the LLVM bytecode documentation. The
> document I have at present just supports the bytecodes my code
> generator processes, though, which is far from all of them. As I get
> farther along with my code generator I expect I'll get to the point
> where everything kind of fits
2006 Oct 26
0
[LLVMdev] Some basic questions about LLVM version 1.8 bytecode format
Hi Robert,
On Wed, 2006-10-25 at 16:00 -0600, Robert Mykland wrote:
> I generated LLVM bytecode for a "hello world!" program just to get the
> basic bytecode structure. I have a few questions about the global
> info module and the global constants module where there have
> apparently been changes since 1.4.
Okay.
> I would be happy to collect these differences and do
2016 Jan 08
2
Is it a va_arg bug in clang?
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
2016 Jan 09
2
[cfe-dev] Is it a va_arg bug in clang?
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
2004 Aug 21
2
[LLVMdev] More Encoding Ideas
At 02:05 PM 8/20/2004, you wrote:
>Robert Mykland wrote:
>>Dear Chris and Reid:
>
>Hi Robert.
>
>>Some other random ideas I've had as I've been sifting through the new
>>bytecode format. Please let me know what you think.
>>1) ANSI C allows for char to default to unsigned char. This is I guess
>>not how it normally is in GCC. If char defaulted
2004 Aug 24
4
[LLVMdev] More Encoding Ideas
On Mon, 2004-08-23 at 19:46, Robert Mykland wrote:
> At 06:43 PM 8/20/2004, Chris Lattner wrote:
> >I don't understand what you're getting at here. You can change char to
> >default to unsigned right now with llvm-gcc -funsigned-char. I don't
> >understand how that would change anything to be more useful though.
>
> Well, in the old days, char strings were
2004 Aug 16
2
[LLVMdev] Bytecode file bugs / doc bugs
Dear Reid and Chris,
I thought I should send this to the list in case anyone else is struggling
to interpret bytecode files with the new docs.
(1) First a bug I already mentioned to Reid. Unlike the other new
module headers module 0x01 still uses the old 32-bit and 32-bit format
instead of the new 5-bit and 27-bit format. Thus the first module in the
file will be 0x00000001 followed by
2004 Aug 20
4
[LLVMdev] More Encoding Ideas
Dear Chris and Reid:
Some other random ideas I've had as I've been sifting through the new
bytecode format. Please let me know what you think.
1) ANSI C allows for char to default to unsigned char. This is I guess not
how it normally is in GCC. If char defaulted to unsigned char several
things would be possible. Single char constants that are defined would be
almost always stored
2006 Oct 05
3
[LLVMdev] Extracting all BasicBlocks of a Function into new Function
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);
2006 Oct 03
2
[LLVMdev] Extracting all BasicBlocks of a Function into new Function
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
2004 Aug 21
4
[LLVMdev] More Encoding Ideas
On Fri, 20 Aug 2004, Robert Mykland wrote:
> >In any case, both signed and unsigned 8-bit constants can be written out
> >in a single byte. Again, do you think it's worth special casing this
> >though? Considering that we handle 8-bit strings specially already, there
> >are not a ton of 8-bit constants with value >= 128.
>
> I'd rather that they not be
2007 Apr 18
2
libswfdec/jpeg
libswfdec/jpeg/jpeg_rgb_decoder.c | 1 -
1 files changed, 1 deletion(-)
New commits:
diff-tree 15ed4a69b4ffc265fe103ba79a0b60af7e42a9fa (from 2073f39bc0b0aa90f1f67def9bb3f0c6b68018ae)
Author: Benjamin Otte <otte@gnome.org>
Date: Wed Apr 18 10:47:06 2007 +0200
remove leftover debugging statement
diff --git a/libswfdec/jpeg/jpeg_rgb_decoder.c b/libswfdec/jpeg/jpeg_rgb_decoder.c
2004 Aug 20
0
[LLVMdev] More Encoding Ideas
Robert Mykland wrote:
> Dear Chris and Reid:
Hi Robert.
>
> Some other random ideas I've had as I've been sifting through the new
> bytecode format. Please let me know what you think.
>
> 1) ANSI C allows for char to default to unsigned char. This is I guess
> not how it normally is in GCC. If char defaulted to unsigned char
> several things would be
2006 Oct 03
0
[LLVMdev] Extracting all BasicBlocks of a Function into new Function
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
2004 Aug 21
0
[LLVMdev] More Encoding Ideas
On Fri, 2004-08-20 at 17:39, Robert Mykland wrote:
> No, you're not getting the point. The bytecode is bloated by pointers to
> all types. Every time a type is defined pretty much a pointer is defined
> with it already, and since the pointer type is not implied by the
> definition of the literal, we waste two or more bytes whenever we define a
> type. I'm advocating
2004 Aug 21
2
[LLVMdev] More Encoding Ideas
On Fri, 2004-08-20 at 17:55, Robert Mykland wrote:
> At 05:09 PM 8/20/2004, Chris Lattner wrote:
> >
> >If you're interested in the plans, they are described in some detail here:
> >http://nondot.org/sabre/LLVMNotes/TypeSystemChanges.txt
> >
> >Note that there is no concrete timeline for this to happen, it basically
> >depends on when someone is ambitious
2004 Aug 26
0
[LLVMdev] More Encoding Ideas
At 09:37 PM 8/23/2004, you wrote:
>On Mon, 2004-08-23 at 19:46, Robert Mykland wrote:
> > At 06:43 PM 8/20/2004, Chris Lattner wrote:
> > >I don't understand what you're getting at here. You can change char to
> > >default to unsigned right now with llvm-gcc -funsigned-char. I don't
> > >understand how that would change anything to be more useful