search for: pointer_typ

...because my declaration and use of sprintf is wrong. I notice llvm-gcc produces declarations containing "..." like: declare int %printf(sbyte*, ...) but I'm not sure how to do this so I've used: let sprintf = declare_function "sprintf" (function_type (pointer_type i8_type) [| pointer_type i8_type; pointer_type i8_type; i32_type |]) m in which gives: declare i8* @sprintf(i8*, i8*, i32) What is the correct way to do this? -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e

...lvm-gcc-4.2-objects/../llvm-objects/include -I/tmp/llvm-build/2.7/llvm/include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder \ -c ../../llvm-gcc-4.2/gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o GCC: <pointer_type 0x41a1b130 type <void_type 0x41a1b080 void VOID align 8 symtab 1 alias set -1 LLVM: void pointer_to_this <pointer_type 0x41a1b130>> public unsigned DI size <integer_cst 0x41a08b70 type <integer_type 0x41a1a0b0 bit_size_type> constant invari...

...not sure why. I think it > might be because my declaration and use of sprintf is wrong. > > I notice llvm-gcc produces declarations containing "..." like: > > declare int %printf(sbyte*, ...) > > What is the correct way to do this? The type you want is: let sp = pointer_type i8_type in var_arg_function_type sp [| sp; sp |] — Gordon

...ad20 type <real_type 0x141d1e0a8 real(kind=8) DF size <integer_cst 0x141d01a50 constant 64> unit size <integer_cst 0x141d01a78 constant 8> align 64 symtab 0 alias set 2 canonical type 0x141d1e0a8 precision 64 pointer_to_this <pointer_type 0x141d1e2a0> reference_to_this <reference_type 0x141e720a8>> V2DF size <integer_cst 0x141d01c58 constant 128> unit size <integer_cst 0x141d01c80 constant 16> align 128 symtab 0 alias set 2 canonical type 0x141d6ad20 nunits 2 pointer_t...

On 4/9/2011 6:09 AM, Duncan Sands wrote: > Hi Jack, thanks for the numbers. Any chance of analysing why gcc does better on > those where it does much better than dragonegg? > > Ciao, Duncan. Also, does -fplugin-arg-dragonegg-enable-gcc-optzns get Dragonegg to match GCC performance where GCC was faster? Marcus

...type 0x200008f96b0 va_list sizes-gimplified no-force-blk BLK        size <integer_cst 0x20000820ea0 constant invariant 128>        unit size <integer_cst 0x20000820ed0 constant invariant 16>        align 64 symtab 0 alias set -1        fields <field_decl 0x20000846180 __base type <pointer_type 0x20000833130>            unsigned asm-frame-size 0 DI file <built-in> line 0            size <integer_cst 0x20000820b70 constant invariant 64>            unit size <integer_cst 0x20000820ba0 constant invariant 8>            align 64 offset_align 128            offset <inte...

On Fri, 1 Sep 2006, Michael McCracken wrote: > Here's what works now, and I have a separate test case for each of these: > > statement functions > intrinsic functions (print, cos, etc) > loops, goto statments > scalarized array operations > function calls with *no arguments* > simple common blocks Great! > Function calls with more than one argument don't work.

On Monday 26 November 2007 00:40, Gordon Henriksen wrote: > The type you want is: > > let sp = pointer_type i8_type in > var_arg_function_type sp [| sp; sp |] Awesome stuff. Here is my most elegant Fibonacci example in OCaml so far: open Llvm let ( |> ) x f = f x let int n = const_int i32_type n let return b x = build_ret x b |> ignore let build_fib m = let ty = function_type i32_ty...

The NIST F77 test suite doesn't seem to be compatible with gfortran at all, so I had to work from my own sample codes, and generate test cases from them. Here's what works now, and I have a separate test case for each of these: statement functions intrinsic functions (print, cos, etc) loops, goto statments scalarized array operations function calls with *no arguments* simple common

...) call debug_tree(decl) <function_decl 0xb7b9d618 _X_ZNSt19istreambuf_iteratorIcSt11char_traitsIcEEppEv type <function_type 0xb7ab7e88 type <void_type 0xb7ab5b40 void sizes-gimplified type_6 VOID align 8 symtab 146744576 alias set -1 pointer_to_this <pointer_type 0xb7ab5bb8>> type_6 QI size <integer_cst 0xb7aa139c constant invariant 8> unit size <integer_cst 0xb7aa13b8 constant invariant 1> align 8 symtab 0 alias set -1 arg-types <tree_list 0xb7aa1efc value <void_type 0xb7ab5b40 void>>...

...f [|sub|] "fibx2" recurseb in let sum = build_add callfibx1 callfibx2 "addresult" recurseb in build_ret sum recurseb; fibf let main filename = let m = create_module filename in let puts = declare_function "puts" (function_type i32_type [|pointer_type i8_type|]) m in let fib = build_fib m in let main = define_function "main" (function_type i32_type [| |]) m in let at_entry = builder_at_end (entry_block main) in let n = build_call fib [| const_int i32_type 40 |] "" at_entry in ignore (build_ret (const_null...

On Mon, 11 Sep 2006, [UTF-8] Rafael Esp?ndola wrote: > I am trying to build llvm-gcc4 on a amd64. I had to add the attached > patch to get the build system to select the correct library. Now the Applied. > build fails while compiling a code that has __builtin_va_copy. The > attached test.i fails with: > > cc1: ../../trunk/gcc/llvm-convert.cpp:443: llvm::Value* >

I am trying to build llvm-gcc4 on a amd64. I had to add the attached patch to get the build system to select the correct library. Now the build fails while compiling a code that has __builtin_va_copy. The attached test.i fails with: cc1: ../../trunk/gcc/llvm-convert.cpp:443: llvm::Value* TreeToLLVM::Emit(tree_node*, llvm::Value*): Assertion `(isAggregateType(((exp)->common.type)) == (DestLoc

...ic value type and use lots of bitcasts. The value type is either the native integer (i32 or i64 depending on target) or a pointer type, probably the recursive pointer type: let value_ty = let temp_ty = opaque_type () in let h = handle_to_type temp_ty in refine_type temp_ty (pointer_type temp_ty); type_of_handle h Since LLVM does not have an intptr type, you'd need to know your target and parameterize your codegen accordingly to use the integer types. The bitcasts have no runtime cost, and LLVM optimization passes can simplify them. Your compiler's semantic an...

...param fn 0) :: (f, fn) :: vars in let body, state = expr { fn = fn; blk = entry_block fn; vars = vars' } body in build_ret body (bb state) |> ignore; (f, fn) :: vars let int n = const_int i32_type n let main filename = let m = create_module filename in let string = pointer_type i8_type in let print = declare_function "printf" (var_arg_function_type i32_type [|string|]) m in let main = define_function "main" (function_type i32_type [| |]) m in let blk = entry_block main in let bb = builder_at_end blk in let str s = define_global "...

Evan Cheng wrote: > Hi, > > Here is the follow on patch for this problem. Please apply this from > the top of the tree and rebuild. With the patch from Chris and then the patch from you combined, the previous error disappeared, but I get another error, reduced to this: ./cc1 -fpreprocessed libgcc2.i -quiet -dumpbase libgcc2.c -mtune=pentiumpro -auxbase-strip libgcc/./_clz.o -g -O2

...;integer_cst 0x41a08b70 type <integer_type 0x41a1a0b0 bit_size_type> > constant invariant 64> >   unit size <integer_cst 0x41a08ba0 type <integer_type 0x41a1a000 long > unsigned int> constant invariant 8> >   align 64 symtab 0 alias set -1 >   pointer_to_this <pointer_type 0x41a2cbb0>> > LLVM: i8* (32 bits) > LLVM type size doesn't match GCC type Indeed, LLVM assumes that pointer size is 32 bits (since it's 32 bit sparc), but gcc - definitely not. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg St...

...in (* @greeting = global [14 x i8] c"Hello, world!\00" *) let greeting = define_global "greeting" (const_stringz "Hello, world!") m in (* declare i32 @puts(i8* ) *) let puts = declare_function "puts" (function_type i32_type [| pointer_type i8_type |]) m in (* define i32 @main() { entry: *) let main = define_function "main" (function_type i32_type [| |]) m in let at_entry = builder_at_end (entry_block main) in (* %tmp = getelementptr [14 x i8]* @greeting, i32 0, i32 0 *) let zero = const_...

...r, which is discussed here: http://llvm.org/docs/ProgrammersManual.html#BuildRecType The file test/Bindings/Ocaml/vmcore.ml contains this fragment: (* RUN: grep -v {RecursiveTy.*RecursiveTy} < %t.ll *) let ty = opaque_type () in let th = handle_to_type ty in refine_type ty (pointer_type ty); let ty = type_of_handle th in insist (define_type_name "RecursiveTy" ty m); insist (ty == element_type ty) Which constructs %RecursiveType = type %RecursiveType*. >> Finally, just as the C++ STL has reverse_iterator, it did prove >> necessary to have a separ...

...0060 bit_size_type> constant invariant >>> 96> >>> unit size <integer_cst 0x7ff01100 type <integer_type 0x7ff80000 >>> unsigned int> constant invariant 12> >>> align 32 symtab 0 alias set -1 precision 80 >>> pointer_to_this <pointer_type 0x7ff80c60>> >>> >> >> as I thought, it's a problem with long double. GCC thinks it is 12 bytes >> long, LLVM presumably thinks it is 16 bytes long [in reality long double >> is 10 bytes long, but here sizes include alignment, and different OS's >...