similar to: [LLVMdev] RFC: Store alignment should be LValue alignment, not source alignment

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

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

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

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

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

Hi Chris, > The static code generator works for many simple cases, but it is currently > disabled. To enable it, uncomment this line in > llvm-gcc/gcc/llvm-convert.cpp: > > //#define ITANIUM_STYLE_EXCEPTIONS > > > Based on that, you should be able to compile simple C++ codes that throw > and catch exceptions. The next step would be to make a .bc file, run it

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

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

> Also sprach Wojciech Stryjewski: > } Ok. Let's say I have a GetElementPtrInst that is used to access > structure > } elements. In this case the indexes will be constants and I want > to get the > } constant values as an a native C int. > } > } Now I can iterate over all the indexes with idx_begin(). I can cast > } all of the indexes to a ConstantIntegral. However,

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

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

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