similar to: [LLVMdev] gmake check failures on FreeBSD 5.4

Two unexpected failures are occurring: FAIL: /usr/home/jeffc/llvm/obj/../test/Regression/CodeGen/X86/shift-double.llx: FAIL: /usr/home/jeffc/llvm/obj/../test/Regression/Transforms/InstCombine/2004-11-27-SetCCForCastLargerAndConstant.ll: %Y = cast sbyte %SB to uint ; <uint> [#uses=1] %Y = cast sbyte %SB to int ; <int> [#uses=1] %Y =

Hello! I get some odd behaviour using my structs: "myKernelMap" = type {int (sbyte*)*, int ()*} "Kernel" = type {"myKernelMap"*} The second member ( int()* ) is a pointer to the %getchar() function. I want to call getchar using this function: int "callmyKernelgetchar_kernel"("Kernel"* "myKernel") { "PTRMAP" =

Anders Alexandersson wrote: > Hello! > > I get some odd behaviour using my structs: > > "myKernelMap" = type {int (sbyte*)*, int ()*} > "Kernel" = type {"myKernelMap"*} > > The second member ( int()* ) is a pointer to the %getchar() function. > > I want to call getchar using this function: > > int

Hello! I'm having trouble with pointer traversing. I have a design as follows: class -> map -> classFunctions Starting with a pointer to the class, I want to get a pointer to a classFunction via a pointer to the map. I can't get that function pointer! How shall I think to get the traversing right (see code below)? Is it something with the fact that I am using only pointers in my

On Mon, 3 May 2004, Anders Alexandersson wrote: > Hello! > > I'm having trouble with pointer traversing. I have a design as follows: > class -> map -> classFunctions > > Starting with a pointer to the class, I want to get a pointer to a > classFunction via a pointer to the map. Okay... > I can't get that function pointer! > > How shall I think to get

> Okay, I took a closer look at your output. > > I was correct in that gccas is attempting to assemble a native PPC > assembly language file. However, this appears to be happening because > the assembly file is generated by the GCC Makefiles for libgcc2 (in > llvm-gcc/gcc/config/rs6000/t-ppccomm, I think). > > The first thing I would try is Marco's suggestion: add

On Fri, 20 Aug 2004, Reid Spencer wrote: > On Fri, 2004-08-20 at 18:43, 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. > > The only thing it would change is

On Fri, 2004-08-20 at 19:10, Chris Lattner wrote: > On Fri, 20 Aug 2004, Reid Spencer wrote: > > > > The only thing it would change is that character constants with values > > > 63 would get encoded in 1 byte instead of 2 (with current > > implementation). I'm making a change that will ALWAYS encode UByteTyID > > and SByteTyID constants in 1 byte which would

On Fri, 20 Aug 2004, Reid Spencer wrote: > > It's 127 right, not 63? Also, what does this have to do with sbyte vs > > ubyte? > > No, its 63. Signed bit takes up one bit and "continue bit" takes up > another so signed values 0-63 get the first byte and 64-127 get the > second, etc. Just to clarify, it's actually -64 -> 63 that are one byte values.

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

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

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

Hi all, I just checked in a series of patches that makes some substantial changes to the LLVM getelementptr instruction. In particular, in LLVM 1.2 and earlier, the getelementptr instruction required index operands for structure types to be 'ubyte' constants and index operands for sequential types to be 'long' values. This had several problems, most notably that it was

Hello, I'm having problems with the following LLVM instruction %tmp.0.i = call int (sbyte*, ...)* %printf( sbyte* getelementptr ([11 x sbyte]* %.str_1, long 0, ...... The first argument in function call, sbyte* getelementptr ([11 x sbyte]* %.str_1..... appears to be ConstantExpression*, and my backend does not support ConstantExpression yet. I probable can implement

Distinguished LLVM Creators, I've been looking through the bytecode representation of the type definition table and had a few questions about it. There's an enum in Types.h that defines all bytecodes that represent the primitive types and a few other necessary things: 0 = 0x00 = Void 1 = 0x01 = Bool 2 = 0x02 = UByte 3 = 0x03 = SByte 4 = 0x04 = UShort (16 bits) 5 = 0x05 =

Hi Chris, Congrats on getting this taken care of finally. I know its something you've wanted to do since 1.0. I have one question. How does LLVM disambiguate between a uint used for a structure and a uint used for an array? My assumption is that LLVM is aware of the type of the thing being indexed all the way through the dereference so it doesn't really matter what index type is being

Hello! I'm compiling code which uses pointers as iterators. For some reason--probably a silly misunderstanding of the docs--I can't eliminate duplicate pointer loads. I'll probably figure this out eventually, but if somebody else sees the answer instantly, I certainly won't complain. :-) Here are the optimizers I'm running: opt -f -simplifycfg -dce -instcombine

I'm trying to figure out the unwind primitive. I've written a program which should: 1. Recursively grow the stack until it reaches a threshold 2. Then unwind and print a message Instead what happens is: 1. Recursively grow the stack until it reaches a threshold 2. Then it dies with: Abort trap Can you point me to an example using uwind that "works" ? Thanks. Here's the

int %nlz10(uint %param.x) { %.t3 = shr uint %param.x, ubyte 1 ; <uint> [#uses=1] %.t4 = or uint %.t3, %param.x ; <uint> [#uses=2] %.t7 = shr uint %.t4, ubyte 2 ; <uint> [#uses=1] %.t8 = or uint %.t7, %.t4 ; <uint> [#uses=2] %.t11 = shr uint %.t8, ubyte 4 ; <uint> [#uses=1]

Currently, Structure layout is left to targets, which implement them according to the ABI of that platform. While this is fine for most structures, it makes packed structures very ugly. All fields in a packed type must be converted to byte arrays with casts to access fields, which bloats accesses and obsfucates the types. First class support for packed types would clean up the generated code