Displaying 20 results from an estimated 3000 matches similar to: "[LLVMdev] LLVM conference"
2006 Nov 06
0
[LLVMdev] Problems building cfrontend 4 source on SUSE 10.1
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=us-ascii" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<b>Reid,<br>
<br>
I followed the steps but got stuck as described
2006 Nov 06
0
[LLVMdev] Problems building cfrontend 4 source on SUSE 10.1
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=utf-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Reid,<br>
<br>
Here's the backtrace you asked for:<br>
<br>
2006 Nov 06
4
[LLVMdev] Problems building cfrontend 4 source on SUSE 10.1
This is an libpath problem. When xgcc runs it wants to dynamically link
the libgcc.so. When you run it from the command line it will find your
system libgcc.so (which works) and so you don't see the segfault. When
you run xgcc from the Makefile, it will have set LD_LIBRARY_PATH to get
your <cfebuilddir>/gcc directory which will find the libgcc.so that it
just built, which is the one
2004 Aug 24
0
[LLVMdev] More Encoding Ideas
At 06:14 PM 8/20/2004, Reid Spencer wrote:
> > > > I think the original plan was to have multiple modules in them but
> this
> > > seems
> > > > to have gone by the wayside. The result of linking two (or more)
> > > modules is a
> > > > single module so except in some really bizare corner cases the need for
> > > > multiple
2004 Aug 24
0
[LLVMdev] More Encoding Ideas
At 06:43 PM 8/20/2004, Chris Lattner wrote:
>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
2006 Nov 06
2
[LLVMdev] Problems building cfrontend 4 source on SUSE 10.1
Hi Robert,
On Mon, 2006-11-06 at 12:45 -0800, Robert Mykland wrote:
> Reid,
>
> Here's the backtrace you asked for:
>
> (gdb) bt
> #0 0x0862d65c in llvm::LiveVariables::runOnMachineFunction ()
Hmm, this is a little strange. Your LLVM build is non-debug (there's no
line numbers or arguments in any of the llvm related calls). However,
your llvm-gcc build seems to have
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
2004 Aug 24
1
[LLVMdev] More Encoding Ideas
At 06:08 PM 8/20/2004, you wrote:
>So, to be explicit, what you're advocating is that:
>
>Even Slot Number:
> Type = Types[ slot_num / 2 ]
>Odd Slot Number:
> Type = Pointer[ slot_num / 2 ]
>
>Yes?
Exactly.
>Essentially this eliminates pointer types from the type list altogether.
>Cool idea.
>
>Where's the patch? :)
>
>Seriously
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 21
0
[LLVMdev] More Encoding Ideas
At 05:09 PM 8/20/2004, you wrote:
>On Fri, 20 Aug 2004, Reid Spencer wrote:
> > > defined would be almost always stored in one byte instead of the present
> > > usual two.
> >
> > So, if I get you correctly, you're advocating the creation of a
> Type::CharTyID
> > in the TypeID enumeration that is always written as a single byte? Note
> that
>
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
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 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
2006 Nov 06
1
[LLVMdev] Problems building cfrontend 4 source on SUSE 10.1
Hi Robert,
Please make sure that you:
1. Completely rebuild LLVM (make clean; make reconfigure; make
tools-only)
2. Completely rebuild llvm-gcc (wipe out the build dir with rm -rf,
configure llvm-gcc
and rebuild it)
If you've done that, then please enter the debugger and get a stack
trace for us.
You will need to:
1. Capture the xgcc compile command that failed
2. Run that command
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
2006 Nov 06
3
[LLVMdev] Problems building cfrontend 4 source on SUSE 10.1
I was having video problems, so upgraded my Linux box from SUSE 9.3,
where LLVM frontend 4 source built fine, to SUSE 10.1, where I got the
error message:
../../llvm-gcc4-1.8-source/gcc/libgcc2.c:541: internal compiler error:
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://llvm.org/bugs> for instructions.
This version of SUSE
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
2004 Aug 17
2
[LLVMdev] Re: Bytecodes & docs
Reid,
Thanks for the detailed feedback.
A value of zero now means zero literal for everything except labels,
right? There is kind of a vague reference to this in the 1.0 -> 1.1
section I believe. You might want to make this clearer when talking about
values in the body of the document.
--> A comment on this: if a value of zero were never used for labels, that
would make me happy,
2003 Aug 26
3
[LLVMdev] Seemingly ambiguous parameter lists
LLVMers,
And while we're on the subject to the type definitions table, what's the
difference between
0e 07 01 00
function returning Int ( Void )? Function returning Int ( ... )?
and
0e 07 00
Function returning Int ()
I'm guessing the former really is a function returning Int ( ... ), but how
is the callee supposed to decode the parameter list? I'm an old callee and
I
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