similar to: [LLVMdev] "Value has wrong type!" on Bool:4 bitfield

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 =

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().

How about this patch then? -bw Index: gcc/llvm-convert.cpp =================================================================== --- gcc/llvm-convert.cpp (revision 43658) +++ gcc/llvm-convert.cpp (working copy) @@ -758,7 +758,7 @@ } -Value *TreeToLLVM::Emit(tree exp, Value *DestLoc) { +Value *TreeToLLVM::Emit(tree exp, Value *DestLoc, unsigned Alignment) {

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

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 x i8]* @C.103.30698, i32 0, i32 0), i64 11, i32 8 ) Notice that it has an 8-byte alignment. However, the Bar

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 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

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

Here you go: Starting program: /home/chandlerc/code/compilers/build/llvm-gcc/gcc/cc1 -fpreprocessed -march=k8 testcase.i -o /dev/null warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fff0d5fe000 [Thread debugging using libthread_db enabled] foocc1: /home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp:81: const llvm::Type* llvm_set_type(tree_node*, const

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

any ideas what library has these symbols lang_eh_catch_all get_pointer_alignment validate_arglist i get these linker errors when trying to link llvm-gcc: make[1]: Entering directory `/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree' make[2]: Entering directory

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

Here's a cute bug in llvm-gcc's struct translation: struct S242 { char * a;int b[1]; } ; struct S93 { __attribute__((aligned (8))) void * a; } ; The second example is padded out to 8 bytes, 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

Chris Lattner wrote: > On Thu, 2 Mar 2006, Chris Lattner wrote: >>> Any ideas what could be wrong? >> >> Sorry for the delay, please try this tarball: >> http://nondot.org/sabre/2006-03-02-llvm-gcc-4.tar.gz > > Actually, do to a recent change in CVS, this tarball will probably not > work anymore. Please apply the attached (small) patch on top of it 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* >

The GCC DejaGNU testsuite has discovered some regressions. Here's one; this was reduced from testsuite/gcc.apple/4656532.c: typedef long long __m64 __attribute__ ((__vector_size__ (8), __may_alias__)); static __inline __m64 __attribute__((__always_inline__, __nodebug__)) _mm_slli_si64 (__m64 __m, int __count) { } __m64 x, y; void t1(int n) { y = _mm_slli_si64(x, n); } Compiled with

Dear All, I’m working 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

I am new to LLVM, and I'm trying to compile llvm and llvm-gcc from subversion on a Solaris10/SPARC machine. I have already tried building llvm-2.4 on this machine, but it failed. I then tried the subversion sources (rev. # 65253 fro llvm and rev#65263 for llvm-gcc) and llvm at least builds correctly ( I however have not tried testing it!). I can execute binaries located in

See 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 =

Hello, Trying to get my machine building up-to-date, and a nightly going, i ran into an assertion during the build of llvm-gcc 4.2: $ make -j2 <snip!> /home/chandlerc/code/compilers/build/llvm-gcc/./gcc/xgcc -B/home/chandlerc/code/compilers/build/llvm-gcc/./gcc/ -B/home/chandlerc/code/compilers/install/llvm-gcc/x86_64-pc-linux-gnu/bin/