search for: pointer_to_thi

...-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 invariant 64> unit size <integer_cst 0x41a08ba0 type <integer_type 0x41a1a000 long unsigned int> constant invariant 8>...

...;vector_type 0x141d6ad20 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...

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

...frame 2 gives: (gdb) 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 0xb7ab5b...

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

...         align 64 offset_align 128            offset <integer_cst 0x20000820510 constant invariant 0>            bit offset <integer_cst 0x20000821530 constant invariant 0> context <record_type 0x200008440b0 __va_list_tag> chain <field_decl 0x200008460c0 __offset>>        pointer_to_this <pointer_type 0x20000b4c210>>    addressable used asm-frame-size 0 BLK file ../../source/gcc/libgcov.c line 818 size <integer_cst 0x20000820ea0 128> unit size <integer_cst 0x20000820ed0 16>    align 64 context <function_decl 0x20000b08300 __gcov_execl>    LLVM: %struct.v...

...ld. >   size <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, Sa...

...;integer_type 0x7ff80060 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 differ...

Hi Chandler, > void > foo () { > float x __attribute__ ((mode (XF))); > } nice reduction. I don't see any problem on x86-32, and I don't have access to an x86-64 box right now. Can you please open a PR for this, and also run in the debugger. When you hit the abort, use "up" to go up a stack frame or two or three, and print out the gcc types [use: call

...size <integer_cst 0x2b709d6f39c0 type <integer_type 0x2b709d6e4370 bit_size_type> constant invariant 96> unit size <integer_cst 0x2b709d6f39f0 type <integer_type 0x2b709d6e42c0 long unsigned int> constant invariant 12> align 32 symtab 0 alias set -1 precision 80 pointer_to_this <pointer_type 0x2b709d6f89a0>> (gdb) On Thu, Mar 27, 2008 at 1:18 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Chandler, > > > > void > > foo () { > > float x __attribute__ ((mode (XF))); > > } > > nice reduction. I don't se...

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 getting an assertion firing while building TOT llvm-gcc on Cygwin in libgcc2.c :- /home/ang/build/llvm-gcc/./gcc/xgcc -B/home/ang/build/llvm-gcc/./gcc/ -B/home/an g/llvm-gcc/i686-pc-cygwin/bin/ -B/home/ang/llvm-gcc/i686-pc-cygwin/lib/ -isystem /home/ang/llvm-gcc/i686-pc-cygwin/include -isystem /home/ang/llvm-gcc/i686-pc-c ygwin/sys-include -O2

...t 0x41704930 constant invariant 64> unit size <integer_cst 0x41704960 constant invariant 8> align 64 symtab 12 alias set -1 precision 64 min <integer_cst 0x417048a0 -9223372036854775808> max <integer_cst 0x417048d0 9223372036854775807> LLVM: i64 pointer_to_this <pointer_type 0x41731070> reference_to_this <reference_type 0x4175f310>> arg 0 <var_decl 0x417742a0 D.926 type <integer_type 0x4170a4d0 int8> used ignored asm-frame-size 0 DI file /sw/src/fink.build/llvm-gcc42-2.4-1/llvm-gcc4.2-2.4.source/gcc/testsuite/gfort...

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

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.

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

...et <integer_cst 0x45e23150 constant invariant 0> bit offset <integer_cst 0x45e23c60 constant invariant 0> context <record_type 0x45e4c180 int_info> arguments <integer_cst 0x45e23150 0> LLVM: uint 0 chain <field_decl 0x45e4c280 range>> pointer_to_this <pointer_type 0x45e4c580> chain <type_decl 0x45e4c300 D.269>> arg 0 <tree_list 0x45e49840 purpose <field_decl 0x45e4c200 kind> value <integer_cst 0x45e23db0 constant invariant 1> chain <tree_list 0x45e49860 purpose <field_decl 0x45e4c280 ran...

Bam. This is about as reduced as it gets. I think I can spot the problem point: chandlerc at osiris ~/code/compilers/build/llvm-gcc $ cat testcase.i void foo () { float x __attribute__ ((mode (XF))); } chandlerc at osiris ~/code/compilers/build/llvm-gcc $ ./gcc/cc1 -fpreprocessed -march=k8 testcase.i -o /dev/null foocc1: /home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp:81: const