similar to: [LLVMdev] RFC: llvm-convert.cpp Patch

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

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

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

I have the following list of strings: x <- c("foo, foo2, foo3", "bar", "qux, qux1") what I want to do is to obtain foo, bar qux Namely for each element in the vector obtain only string before the first comma. What's the way to do it? - G.V. [[alternative HTML version deleted]]

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

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

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 =

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

On Mon, 6 Mar 2006, Vladimir Prus wrote: > ../../2006-03-02-llvm-gcc-4/gcc/llvm-convert.cpp:1305: error: parse error > before `__attribute__' Can you send me the preprocessed .i file for this file? To work around the above error, just remove "ATTRIBUTE_UNUSED" from that line. > ../../2006-03-02-llvm-gcc-4/gcc/llvm-convert.cpp: In function `tree_node* >

Interestingly, in the .i file there are 2 __builtin_alloca, and EmitBuiltinAlloca is only being called once. Andrew On 2/16/08, Andrew Lenharth <andrewl at lenharth.org> wrote: > libcpp/charset.c:631 turns into: > > %tmp16 = tail call i64 @strlen( i8* %to ) nounwind readonly > ; <i64> [#uses=1] > %tmp18 = tail call i64 @strlen( i8* %from ) nounwind

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

Despite the commit of... ------------------------------------------------------------------------ r135371 | lattner | 2011-07-18 00:25:32 -0400 (Mon, 18 Jul 2011) | 2 lines untested patch to de-constify llvm::Type, patch by David Blaikie! current dragonegg svn at r135391 still fails to compile against FSF gcc 4.5.3 with the failure... In file included from

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

Chris Lattner wrote: > On Mon, 6 Mar 2006, Vladimir Prus wrote: >> ../../2006-03-02-llvm-gcc-4/gcc/llvm-convert.cpp:1305: error: parse > error >> before `__attribute__' > > Can you send me the preprocessed .i file for this file? Sure, I've sent it by private email (180K is too big for list). > To work around the above error, just remove

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

Looks like that break came from http://llvm.org/viewvc/llvm-project?view=rev&revision=135154 Judging by this<http://llvm.org/docs/doxygen/html/classllvm_1_1ArrayRef.html#a3b1f44186f9787d7ffacb54b62d6798c> ArrayRef ctor you should be able to simplify those calls by changing the last two arguments from "&foo, 1" to, simply, "foo". On Mon, Jul 18, 2011 at 6:59 AM,

[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