search for: converttyp

Displaying 20 results from an estimated 21 matches for "converttyp".

Did you mean: converttype
2009 Jan 09
2
[LLVMdev] RFC: Store alignment should be LValue alignment, not source alignment
...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 *Tre...
2010 Jan 07
1
[LLVMdev] "Value has wrong type!" on Bool:4 bitfield
...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...
2009 Jan 09
0
[LLVMdev] RFC: Store alignment should be LValue alignment, not source alignment
...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_T...
2007 Oct 11
0
[LLVMdev] Can't bootstrap llvm-gcc-4.0 for x84_64
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.
2008 Feb 12
2
[LLVMdev] an llvm-gcc bug
...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...
2020 Jan 07
3
Best way of implement a fat pointer for C
...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 act...
2007 Oct 10
3
[LLVMdev] Can't bootstrap llvm-gcc-4.0 for x84_64
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
2013 Feb 08
2
[LLVMdev] assert when mixing static and non-static members with an external AST source
...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...
2011 Jul 28
0
[LLVMdev] Request to review of patch for llvm-gcc
...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...
2007 Aug 22
0
[LLVMdev] RFC: Patch for CFA on Darwin
...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 ge...
2008 Feb 13
0
[LLVMdev] an llvm-gcc bug
...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 ConvertUNIO...
2013 Feb 15
0
[LLVMdev] assert when mixing static and non-static members with an external AST source
...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...
2017 May 29
2
Print 128 bit value at runtime using printf
...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&quot...
2007 Oct 11
3
[LLVMdev] Can't bootstrap llvm-gcc-4.0 for x84_64
...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...
2008 Mar 27
0
[LLVMdev] llvm-gcc 4.2 assertion failed on linux x86_64
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
2008 Mar 27
2
[LLVMdev] llvm-gcc 4.2 assertion failed on linux x86_64
...!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 0x2b709d6f3...
2007 Nov 07
3
[LLVMdev] RFC: llvm-convert.cpp Patch
...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));...
2008 Mar 27
2
[LLVMdev] llvm-gcc 4.2 assertion failed on linux x86_64
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
2007 Nov 07
0
[LLVMdev] RFC: llvm-convert.cpp Patch
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
2009 Feb 19
2
[LLVMdev] please review this fix for PR3510
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