search for: debug_tree

...R) && "Didn't pass DestLoc > to an aggregate expr, or passed it to scalar!"' failed. > > I know that linux/amd64 is not currently supported, but does someone > knows how to fix this? Can you gdb cc1, run until the assertion, then mail the output of "call debug_tree(exp)"? Also, can you include a stack trace with line numbers as well? Thanks, -Chris -- http://nondot.org/sabre/ http://llvm.org/

...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 debug_tree(type) ] and the LLVM type [use: call Ty->dump() ]. Thanks, Duncan.

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

...ype for the function doesn't match up with the arguments. There are two likely answers: 1. We're handling a formal argument incorrectly. 2. We're building the prototype incorrectly. Figuring out which of the two is happening is important. If it's #2, getting the output of "debug_tree(x)" on the function type "tree" node would be useful. If it's #1, getting the output of debug_tree(x) on the argument node that isn't getting converted correctly would be useful. -Chris -- http://nondot.org/sabre/ http://llvm.org/

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

..., Ty=0x166c210) at /home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp:78 78 assert((!TYPE_SIZE(Tr) || !Ty->isSized() || !isInt64(TYPE_SIZE(Tr), true) || (gdb) Ty->dump() Undefined command: "Ty->dump". Try "help". (gdb) call Ty->dump() x86_fp80 (gdb) call debug_tree(type) No symbol "type" in current context. (gdb) up #4 0x0000000000a86501 in TypeConverter::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...

...the bug for a reduction and the gimple trees. validate_arglist definately is rejecting the arglist in EmitBuiltinAlloca. (try: bool TreeToLLVM::EmitBuiltinAlloca(tree exp, Value *&Result) { tree arglist = TREE_OPERAND(exp, 1); if (!validate_arglist(arglist, INTEGER_TYPE, VOID_TYPE)) { debug_tree(arglist); return false; } Value *Amt = Emit(TREE_VALUE(arglist), 0); Amt = CastToSIntType(Amt, Type::Int32Ty); Result = Builder.CreateAlloca(Type::Int8Ty, Amt, "tmp"); return true; } for a pretty (?) print of the tree at that point) Andrew On 2/16/08, Török Edwin <edwin...

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

On Wednesday 10 October 2007 17:12, David Greene wrote: > This particular problem is gone (thanks!) but I'm having other troubles. > I'm tracking those down now. This is the current problem: [x86_64-off-dbg]: ./xgcc -B./ -B/install.official.debug/x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/bin/ -isystem

Hi David, > "LLVM type size doesn't match GCC type size!"' failed. this assertion checks that gcc types are converted into LLVM types of the same size. Try running cc1 in gdb. When you hit the assertion, go up a few stack frames until you get to ConvertType. Do call debug_tree(type) That will tell you what the gcc type was. From that and the LLVM type it should be clear what the ultimate cause of the problem was. Ciao, Duncan.

...re a constant array of int_info structures. range() is an intrinsic function that returns the expoent range of the argument's type kind. I haven't quite been able to figure out where that gets evaluated, but I am pretty sure it should be a constant at compile time. Here's the output of debug_tree() 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 <...

...cision; when using Applied to gcc/gcc/config/i386/i386.h If that doesn't help, please send me a stack trace of the crash. To do this, pass -v to the failing GCC command line, then debug the cc1 invocation. In addition, please go up to the first stack frame with a GCC tree, and 'call debug_tree(exp)' on it from within GDB. That will help me understand what is going on. Thanks, sorry this is taking so many iterations. :( -Chris -- http://nondot.org/sabre/ http://llvm.org/

...gimple trees. validate_arglist > definately is rejecting the arglist in EmitBuiltinAlloca. > > (try: > bool TreeToLLVM::EmitBuiltinAlloca(tree exp, Value *&Result) { > tree arglist = TREE_OPERAND(exp, 1); > if (!validate_arglist(arglist, INTEGER_TYPE, VOID_TYPE)) { > debug_tree(arglist); > return false; > } > Value *Amt = Emit(TREE_VALUE(arglist), 0); > Amt = CastToSIntType(Amt, Type::Int32Ty); > Result = Builder.CreateAlloca(Type::Int8Ty, Amt, "tmp"); > return true; > } > for a pretty (?) print of the tree at that point) This is...

...LLVM type size doesn't match GCC type size!"' failed. > > this assertion checks that gcc types are converted into > LLVM types of the same size. Try running cc1 in gdb. > When you hit the assertion, go up a few stack frames > until you get to ConvertType. Do > call debug_tree(type) > That will tell you what the gcc type was. From that > and the LLVM type it should be clear what the ultimate > cause of the problem was. Ok, I think this must be related to the warning about 64-bit code. debug_type reveals the gcc type to be a function pointer of size 32, which w...

...x084c8207 in assemble_alias (decl=0xb7b9d618, target=0xb698fe00) at ../../2006-03-14-llvm-gcc-4/gcc/varasm.c:4765 #4 0x084d05e6 in rest_of_decl_compilation (decl=0xb7b9d618, top_level=1, at_end=0) at ../../2006-03-14-llvm-gcc-4/gcc/passes.c:204 Printing decl in 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 0xb7...

Chris Lattner wrote: > Here's a new snapshot of the front-end: > http://nondot.org/sabre/2006-03-14-llvm-gcc-4.tar.gz > > This: > > 1. Fixes the inline asm problem you have above. > 2. Includes patches to make it better on Alpha's (thanks to patches by > Andrew Lenharth). > 3. Sync's it up with debug info changes in LLVM CVS (by Jim Laskey). > 4.

Andrew Lenharth wrote: > Interestingly, in the .i file there are 2 __builtin_alloca, and > EmitBuiltinAlloca is only being called once. > > Hmm, here EmitBuiltinAlloca gets called twice, but it looks like validate_arglist is rejecting the args both times. I have 2 calls to alloca generated: $ grep alloca x.bc|grep call %tmp21 = call i8* @alloca( i64 %tmp20 ) nounwind

>> Sorry for the delay, please try this tarball: >> http://nondot.org/sabre/2006-03-02-llvm-gcc-4.tar.gz > > There's some confusion with --enable-llvm configure parameter. I've built > LLVM to a separate build dir. The source is ~ghost/Work/llvm-cvs and build > dir is /space/p2/ghost/build/llvm-cvs ... > So, it seems like, at the same time: > > 1. buildir

Interestingly, in the .i file there are 2 __builtin_alloca, and EmitBuiltinAlloca is only being called once. Andrew On 2/16/08, Andrew Lenharth <andrewl at lenharth.org> wrote: > libcpp/charset.c:631 turns into: > > %tmp16 = tail call i64 @strlen( i8* %to ) nounwind readonly > ; <i64> [#uses=1] > %tmp18 = tail call i64 @strlen( i8* %from ) nounwind

...d to gcc/gcc/config/i386/i386.h > > If that doesn't help, please send me a stack trace of the crash. > To do this, pass -v to the failing GCC command line, then debug the > cc1 invocation. In addition, please go up to the first stack frame > with a GCC tree, and 'call debug_tree(exp)' on it from within GDB. > That will help me understand what is going on. > > Thanks, sorry this is taking so many iterations. :( > > -Chris > > -- > http://nondot.org/sabre/ > http://llvm.org/ > > _______________________________________________ > LLV...