search for: integer_cst

..././libgfortran/.libs -L/sw/src/fink.build/llvm-gcc42-2.4-1/llvm_gcc42_objdir/i686-apple-darwin9/./libiberty -lm -o ./array_constructor_12.exe (timeout = 300) Unhandled expression! TREE_CODE: 68 <floor_div_expr 0x41765f60 type <integer_type 0x4170a4d0 int8 public DI size <integer_cst 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 p...

....cpp:6538) to emit the second argument.  The second argument is the result of an alloca.  TreeToLLVM::Emit is hitting the first assertion (~929). The exp being passed is:  <var_decl 0x20000b44240 ap    type <record_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...

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

Hi Evan, > LValue LV = EmitLV(lhs); > bool isVolatile = TREE_THIS_VOLATILE(lhs); > unsigned Alignment = expr_align(exp) / 8 > > It's using the alignment of the expression, rather than the memory > object of LValue. can't you just use expr_align(lhs) instead? > The patch saves the alignment of the memory object in LValue returned > by EmitLV().

...es of the form... /sw/lib/gcc4.5/bin/gfortran -O3 -fplugin=/sw/lib/gcc4.5/lib/dragonegg.so -fplugin-arg-dragonegg-enable-gcc-optzns ac.f90 -o ac <misaligned_indirect_ref 0x1438ad230 type <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>>...

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

...() for the expression that breaks the assertion: Breakpoint 2, TreeConstantToLLVM::Convert (exp=0x45e48c60) at ../../src/gcc/llvm-convert.cpp:3868 2: exp->common.constant_flag = 0 1: debug_tree (exp) = <constructor 0x45e48c60 type <record_type 0x45e4c180 int_info BLK size <integer_cst 0x45e23870 constant invariant 64> unit size <integer_cst 0x45e238a0 constant invariant 8> align 32 symtab 1183925312 alias set -1 fields <field_decl 0x45e4c200 kind type <integer_type 0x45e28480 int4> asm-frame-size 0 SI file /Users/mike/Documen...

Hi all, Please review this patch. It's fixing PR3232 comment #8. Function bar from 2008-03-24-BitFiled-And-Alloca.c compiles to: %struct.Key = type { { i32, i32 } } ... define i32 @bar(i64 %key_token2) nounwind { entry: %key_token2_addr = alloca i64 ; <i64*> [#uses=2] %retval = alloca i32 ; <i32*> [#uses=2] %iospec =

...../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> align 64 symtab 0 alias set -1 pointer_to_this <pointer_type 0x41a2cbb0>&g...

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

...made in gcc/Makefile in llvm-gcc. The patch is incorrect and the problems you're seeing are caused by your patch, since sparc != sparc64. In LLVM sense "sparc" means "sparc with ILP32 architecture model", llvm does not support anything 64 bit in sparc world. >   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...

...2010/1/10 Duncan Sands <baldrick at free.fr> > > Hi Aaron, >> >> >> Thanks, okay heres the results :- >>> >>> LLVM type size doesn't match GCC type size! >>> >>> <real_type 0x7ff80b40 long double sizes-gimplified XF size <integer_cst >>> 0x7ff010e0 type <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...

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

...eambuf_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>> pointer_to_this <pointer_type 0xb7121ca8>> publ...

...peConverter::ConvertType (this=0x16941a0, orig_type=0x2b709d6f8790) at /home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp:756 756 case 80: return SET_TYPE_LLVM(type, Type::X86_FP80Ty); (gdb) call debug_tree(type) <real_type 0x2b709d6f8790 long double sizes-gimplified XF 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 <poin...

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

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

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