Displaying 20 results from an estimated 4000 matches similar to: "[LLVMdev] type mismatch mystery solved"
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 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 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
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 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
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
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
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
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
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
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
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
2004 Aug 06
1
VBR reencoding @128k problem
I did some further investigating into this issue and here's what I found:
It appears somewhere between ices0.1.0 and ices 0.2.0 is where the "bug" (for lack of a better term) was introduced that i'm noticing. When I compile ices0.2.0 w/lame 3.89beta, the VBR is *NOT* reencoded, but instead streamed out at full VBR bitrate(s). However, when using ices0.1.0 w/lame 3.89beta, it
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
2015 Nov 19
2
Comments WAS: Refactor checksize.pl
> 2015-11-19 17:30 UTC+01:00, Nicolas Cornu via Syslinux <syslinux at zytor.com>:
> > - Remove padsize argument as it is never used.
> > - Add an usage printed when $file is not set or --help, -h
> > is the first argument.
> > - Add basic tests for this script.
> > ---
> > mbr/checksize.pl | 27 ++++++++++++++++++---------
> >
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 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,
2009 Sep 29
2
[LLVMdev] [PATCH] llvm-bcanalyzer: print percentages without scientific notation
Hi,
Andreas Neustifter <astifter-llvm at gmx.at> writes:
> Maybe you can use the already available "include/llvm/Support/Format.h"?
Thanks, that simplifies the patch a lot. See the attached patch.
Btw, llvm-bcanalyzer.cpp seems to also use fprintf -- does mixing it
with errs() cause problems and should it be converted to use format()?
best regards,
Timo Lindfors
2013 Feb 08
1
[LLVMdev] Build failure
Hi all,
After updating llvm+clang to r174701 by issuing
make -j8 happiness
The build fails with:
...
make[2]: Entering directory `/local/csaba/LLVM/build-release/tools/llvm-diff'
llvm[2]: Compiling DiffConsumer.cpp for Release+Asserts build
llvm[2]: Linking Release+Asserts executable lli (without symbols)
llvm[2]: Compiling CrashDebugger.cpp for Release+Asserts build
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
>