search for: converttype

...rn Emit(TREE_OPERAND(exp, 0), 0); + tree Op = TREE_OPERAND(exp, 0); + return LValue(Emit(Op, 0), expr_align(Op) / 8); + } } } @@ -2290,7 +2301,7 @@ Value *TreeToLLVM::EmitLoadOfLValue(tree LValue LV = EmitLV(exp); bool isVolatile = TREE_THIS_VOLATILE(exp); const Type *Ty = ConvertType(TREE_TYPE(exp)); - unsigned Alignment = expr_align(exp) / 8; + unsigned Alignment = LV.getAlignment(); if (TREE_CODE(exp) == COMPONENT_REF) if (const StructType *STy = dyn_cast<StructType>(ConvertType(TREE_TYPE(TREE_OPERAND(exp, 0))))) @@ -2963,7 +2974,7 @@ Value *Tree...

...plus: /home/foad/svn/antix/toolchain/branches/w/foad/2757llvm26/toolchain/llvm/llvm-gcc/gcc/llvm-convert.cpp:999: llvm::Value* TreeToLLVM::Emit(tree_node*, const MemRef*): Assertion `(Result == 0 || (((enum tree_code) (((exp)->common.type))->common.code) == VOID_TYPE) || isa<VectorType>(ConvertType(((exp)->common.type))) || Result->getType() == ConvertType(((exp)->common.type))) && "Value has wrong type!"' failed. At this point Result is "i8 1". ConvertType(TREE_TYPE(exp)) is i4. And the code generated for the basic block so far is: entry: %retval...

...return LValue(Ptr, TYPE_ALIGN(TREE_TYPE(exp)) / 8); > + } These are all equivalent to using expr_align, right? > @@ -2290,7 +2301,7 @@ Value *TreeToLLVM::EmitLoadOfLValue(tree > LValue LV = EmitLV(exp); > bool isVolatile = TREE_THIS_VOLATILE(exp); > const Type *Ty = ConvertType(TREE_TYPE(exp)); > - unsigned Alignment = expr_align(exp) / 8; > + unsigned Alignment = LV.getAlignment(); Here expr_align(exp) is correct I think. > @@ -2963,7 +2974,7 @@ Value *TreeToLLVM::EmitMODIFY_EXPR(tree > > LValue LV = EmitLV(lhs); > bool isVolatile = TREE_TH...

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.

...so both of these look like { i8 *, [1 x i32] } This leads the "struct type factory" StructType::get to think they are the same. But, the second field is marked as Padding in the second case but not the first, and CopyAggregate does not copy Padding. When the second type goes through ConvertType, it is converted to the same llvm Type as the first type, and the StructTypeConversionInfo info is replaced; later copies of the first type then think they don't have to copy the padding, producing wrong code. I'm inclined to remove skipping the Padding in CopyAggregate; that's a...

...king on a project that extends C. I’m adding a new type of pointer that is a fat pointer. It has some metadata about the pointed object besides the starting address of the object. Currently I implemented this pointer as an llvm:StructType. In llvm::Type generation function llvm::Type *CodeGenTypes::ConvertType(QualType T) in the case for clang::Type::Pointer, instead of creating an llvm::PointerType I create an llvm::StructType type for this new type of pointer. And I added some helper code in llvm::StructType and in multiple places I added code to trick the compiler to believe sometimes a struct is actu...

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

...db/tools/clang/lib/CodeGen/CGRecordLayoutBuilder.cpp:969 #16 0x00007ffff4cce43f in clang::CodeGen::CodeGenTypes::ConvertRecordDeclType (this=0xd63d90, RD=0xd6a140) at /home/athirumurthi/git/lldb/tools/clang/lib/CodeGen/CodeGenTypes.cpp:637 #17 0x00007ffff4ccce5e in clang::CodeGen::CodeGenTypes::ConvertType (this=0xd63d90, T=...) at /home/athirumurthi/git/lldb/tools/clang/lib/CodeGen/CodeGenTypes.cpp:295 #18 0x00007ffff4cccd67 in clang::CodeGen::CodeGenTypes::ConvertTypeForMem (this=0xd63d90, T=...) at /home/athirumurthi/git/lldb/tools/clang/lib/CodeGen/CodeGenTypes.cpp:88 #19 0x00007ffff4ccd201 i...

...y the type system changes necessary will result in "T*" sometimes not being converted into a pointer to the LLVM type that T converts to, but a pointer to some other type. Unfortunately I think llvm-gcc assumes in a bunch of places that a "T*" is always turned into a pointer to ConvertType(T). Dragonegg does not suffer from this problem due to a bunch of work I did on it over the last year or so. So what to do about llvm-gcc? Your patch doesn't solve the fundamental issue, just one special case. I think the best approach is to port the dragonegg fix (the current approach is n...

...claration(TheModule, + Intrinsic::eh_dwarf_cfa), + Builder.CreateIntToPtr(ConstantInt::get(Type::Int32Ty, + cfa_offset), + ConvertType(TREE_TYPE(exp)))); return true; } The reason for it: when going to calculate the CFA in LLVM, the original code was adding an offset of type i32 to a pointer. This is fine if pointers are 32-bits, but we get an assert if the types are different. By converting the cfa_offset to a pointer, we get...

...i8 *, [1 x i32] } > This leads the "struct type factory" StructType::get to think they are > the same. > But, the second field is marked as Padding in the second case but not > the first, > and CopyAggregate does not copy Padding. When the second type > goes through ConvertType, it is converted to the same llvm Type as the > first type, > and the StructTypeConversionInfo info is replaced; later copies of the > first type > then think they don't have to copy the padding, producing wrong code. there's some mucking around with padding in ConvertUNION...

...db/tools/clang/lib/CodeGen/CGRecordLayoutBuilder.cpp:969 #16 0x00007ffff4cce43f in clang::CodeGen::CodeGenTypes::ConvertRecordDeclType (this=0xd63d90, RD=0xd6a140) at /home/athirumurthi/git/lldb/tools/clang/lib/CodeGen/CodeGenTypes.cpp:637 #17 0x00007ffff4ccce5e in clang::CodeGen::CodeGenTypes::ConvertType (this=0xd63d90, T=...) at /home/athirumurthi/git/lldb/tools/clang/lib/CodeGen/CodeGenTypes.cpp:295 #18 0x00007ffff4cccd67 in clang::CodeGen::CodeGenTypes::ConvertTypeForMem (this=0xd63d90, T=...) at /home/athirumurthi/git/lldb/tools/clang/lib/CodeGen/CodeGenTypes.cpp:88 #19 0x00007ffff4ccd201 i...

...tempString = tempString + "%+s,"; } } tempString = tempString + "%+d,"; } // if any of the 6 floating point types else if(val->getType()->isFloatingPointTy()) { tempString = tempString + "%+f,"; //Apparently this is needed by printf,otehrwise prints 0.000 val = convertType(val,Type::getDoubleTy(TheContext)); } argsValueVector.push_back(val); ++i; } formatString = formatString + tempString + "\n" ; // For something like printf , insert a format string at the beginning. if( F->isVarArg() ) { // every string is declared as a "global constant"...

...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. Ok, I think this must be related to the warning about 64-bit code. debug_type reveals the gcc type to be a function...

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

...!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 debug_tree(type) <real_type 0x2b709d6f8790 long double sizes-gimplified XF size <integer_cst 0x2b709d6f39...

...value, don't emit a load, just use the result. if (isGCC_SSA_Temporary(exp)) { assert(DECL_LLVM_SET_P(exp) && "Definition not found before use!"); @@ -2540,7 +2541,7 @@ LValue LV = EmitLV(exp); bool isVolatile = TREE_THIS_VOLATILE(exp); const Type *Ty = ConvertType(TREE_TYPE(exp)); - unsigned Alignment = expr_align(exp) / 8; + unsigned DstAlign = expr_align(exp) / 8; if (!LV.isBitfield()) { if (!DestLoc) { @@ -2548,17 +2549,17 @@ Value *Ptr = CastToType(Instruction::BitCast, LV.Ptr, PointerType::get(Ty));...

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 Nov 6, 2007, at 5:45 PM, Bill Wendling wrote: > Hi all, > > This patch is to fix a problem on PPC64 where an unaligned memcpy is > generated. The testcase is this: > > $ cat testcase.c > void Qux() { > char Bar[11] = {0}; > } > > What happens is that we produce LLVM code like this: > > call void @llvm.memcpy.i64( i8* %event_list2, i8* getelementptr ([11

Please review this patch for PR3510 (and <rdar://problem/6564697>). The bug is a failure to handle a "hole" inside an initialized structure, where the hole may be induced by a designated initializer or by alignment: http://llvm.org/bugs/show_bug.cgi?id=3510 The original code was greatly simplified by using FieldNo to index the LLVM fields and the initializer in