similar to: [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

On Nov 6, 2007, at 5:45 PM, Bill Wendling wrote: > $ more testcase.c.t03.generic > Qux () > { > static char C.0[11] = {0}; > char Bar[11]; > > Bar = C.0; > } > > Anyway, it turns out that the gimplifier was generating the correct > alignment, but it was being overridden in assemble_variable(): > > /* On some machines, it is good to increase alignment

On Nov 6, 2007, at 6:07 PM, Dale Johannesen wrote: > > On Nov 6, 2007, at 5:45 PM, Bill Wendling wrote: >> $ more testcase.c.t03.generic >> Qux () >> { >> static char C.0[11] = {0}; >> char Bar[11]; >> >> Bar = C.0; >> } >> >> Anyway, it turns out that the gimplifier was generating the correct >> alignment, but it was

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

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 =

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

Hi all, The patch below is to fix a problem with unaligned memcpys. This program: void Bork() { int Qux[33] = {0}; } will currently produce this LLVM code on PPC64: @C.0.937 = internal constant [33 x i8] zeroinitializer define void @Bork() { entry: %Qux = alloca [33 x i8] %Qux1 = bitcast [33 x i8]* %Qux to i8* call void @llvm.memcpy.i64( i8* %Qux1, i8* getelementptr ([33 x i8]*

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

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

Hi, > I don't get it Bill. llvm should be making memcpy with the right > alignment regardless of how Bar is formed. Changing the alignment of > bar papers over this problem, but we will still get improper alignment > for other cases. Also, DECL_USER_ALIGN isn't appropriate to tweak > here... the user isn't playing around with __attribute__((aligned)) the

On Oct 26, 2007, at 11:12 AM, Bill Wendling wrote: > Hi all, > > The patch below is to fix a problem with unaligned memcpys. This > program: > > void Bork() { > int Qux[33] = {0}; > } > > will currently produce this LLVM code on PPC64: > > @C.0.937 = internal constant [33 x i8] zeroinitializer > > define void @Bork() { > entry: > %Qux = alloca

> How about this patch then? How about this one :) It passes alignment and volatility around with DestLoc. It's not finished because I noticed some bugs in how CopyAggregate and ZeroAggregate handle alignment (problem points marked with "QQ"). Also, I noticed potential problems with how we handle call arguments and return results (what if they are strangely aligned/volatile?),

[Reposted from llvm-bugs mailing list. Also has an updated, hopefully better, patch associated with it.] Hi, The following program causes the LLVM GCC4 front end to ICE: struct A { virtual ~A(); }; template <typename Ty> struct B : public A { ~B () { delete [] val; } private: Ty* val; }; template <typename Ty> struct C : public A { C (); ~C (); }; template

On Nov 7, 2007, at 12:16 AM, Bill Wendling wrote: > On Nov 6, 2007, at 6:07 PM, Dale Johannesen wrote: >> >> Not sure I'm getting it, is this Bar itself or the constructed C.0 >> that's getting realigned? >> > It's C.0 that's getting realigned. OK then, it looks like other people have made the points I was going to, but briefly: Using

One of our developers pointed out that GCC generates something akin to this on Darwin: $ cat t.c __private_extern__ void bar(const char *format, ...) __attribute__ ((format (printf, 1, 2))); void foo(const char *i, const char *b) { bar("this is some error message that is kind of longish."); } $ gcc -arch i386 -S -o - t.c -Os .cstring .align 2 LC0: .ascii "this is some

>From llvm-gcc-4.2/trunk/gcc/llvm-debug.cpp: void DebugInfo::EmitGlobalVariable(GlobalVariable *GV, tree decl) { // Gather location information. expanded_location Loc = expand_location(DECL_SOURCE_LOCATION(decl)); DIType TyD = getOrCreateType(TREE_TYPE(decl)); const char *DispName = GV->getNameStr().c_str(); Isn't this use of c_str() dodgy, because the temporary string returned

Index: gcc/gimplify.c =================================================================== --- gcc/gimplify.c (revision 39923) +++ gcc/gimplify.c (working copy) @@ -179,8 +179,10 @@ /* LLVM LOCAL begin */ #ifndef ENABLE_LLVM /* LLVM wants to know about gimple formal temps. */ - for (t = gimplify_ctxp->temps; t ; t = TREE_CHAIN (t)) - DECL_GIMPLE_FORMAL_TEMP_P (t) = 0; + if

I'm trying to get the Ada gcc front-end to work with LLVM. This series of patches gets things to the point where the Ada compiler builds, though it fails to build itself or the runtime. While I was there I resurrected fortran and java: as with Ada, the compilers build but not the runtimes. Also, I've replaced the gcc 4.0 Ada front-end with a back-port of the Ada front-end from FSF gcc

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

On x86-64 linux, in stage 2, I get: c++ -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -o f951 \ fortran/arith.o fortran/array.o fortran/bbt.o fortran/check.o fortran/data.o fortran/decl.o