similar to: [LLVMdev] Review: minor patches to llvm-gcc-4-2

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

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

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

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

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

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

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 =

Hi, Duncan I saw you started to port dragonegg to gcc 4.6, which is a good news. And I am also trying to do that. The attachment get src/Convert.cpp to compile against gcc-4.6. Now I get a error while compiling dragonegg, --- Compiling Debug.cpp /tmp/chenwj/dragonegg/src/Debug.cpp: In member function 'llvm::DIType llvm::DebugInfo::createArrayType(tree_node*)':

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

[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

Hi all, I'm currently trying to bootstrap llvm-gcc-4.2 from the latest stable LLVM release 2.6 on Solaris SPARC. The compilation with a self-build gcc-4.2.4 goes pretty well, however, I hit a seemingly widely know error during llvm-gcc's bootstrap in getting an assertion during the compile of /data/LLVM/src/GCC/RELEASE_26/gcc/libgcc2.c: /data/LLVM/src/GCC/RELEASE_26/gcc/libgcc2.c: In

I've built a debug build of llvm 2.6, and llvm-gcc 2.6 for arm-elf with --enable-checking=yes. On the attached test case (which is g++.dg/expr/bitfield4.C from the GCC 4.2 testsuite) I get: $ cc1plus bitfield4.ii -emit-llvm-bc -o bitfield4.o -quiet cc1plus: /home/foad/svn/antix/toolchain/branches/w/foad/2757llvm26/toolchain/llvm/llvm-gcc/gcc/llvm-convert.cpp:999: llvm::Value*

On Wed, 30 Aug 2006, Michael McCracken wrote: > Hi, in a thread this afternoon about compiling the Fortran SPEC2000 to > LLVM bytecode, Chris mentioned that it should be possible to compile > to LLVM with the gfortran front end, although no one has necessarily > tried it. Yup. > I was surprised (and happy) to hear this, as under the impression that > it would require a

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

On Wednesday 30 July 2008 18:13:27 Duncan Sands wrote: > 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

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 Feb 16, 2008, at 2:27 PM, Andrew Lenharth wrote: > 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)) { >

Hi all, Here's a potential patch for LLVM-GCC: Index: llvm-convert.cpp =================================================================== --- llvm-convert.cpp (revision 41260) +++ llvm-convert.cpp (working copy) @@ -4240,11 +4240,12 @@ return false; int cfa_offset = ARG_POINTER_CFA_OFFSET(0); - - Result = Builder.CreateCall(Intrinsic::getDeclaration(TheModule, -