similar to: [LLVMdev] ICE in LLVM GCC4 Front End

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 the gcc directory. Worth noting, this front-end only works

On Thu, 2 Mar 2006, Vladimir Prus wrote: >>> The instructions seem to have one path wrong. It says to get: >> >> I'll put together a tarball today. That will be easier than dealing with >> a patch, and it will include a bunch of bugfixes since the previous email. > Further into process, I get this error: > In file included from

Ok, I've tracked down the problem I've had bootstrapping llvm-gcc. The culprit is in TreeToLLVM::EmitMemCpy: void TreeToLLVM::EmitMemCpy(Value *DestPtr, Value *SrcPtr, Value *Size, unsigned Align) { const Type *SBP = PointerType::get(Type::Int8Ty); const Type *IntPtr = TD.getIntPtrType(); Value *Ops[4] = { CastToType(Instruction::BitCast,

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

Full_Name: Wolfgang Huber Version: R-devel_2005-03-10 OS: alphaev68-dec-osf4.0f Submission from: (NULL) (62.253.128.15) This report concerns allocation of large (>2^31 byte) chunks of memory with R_alloc. I suspect it is a bug/typo but please don't hate me if it's actually a feature: In R, I can happily create large matrices: > a= matrix(0, nrow=191481, ncol=3063) > dim(a) [1]

I want to write a little stand-alone C program that calls R_alloc, but I get a segmentation fault: int main(int argc, char** argv){ double* d = (double *)R_alloc(2, sizeof(double)); // <- segmentation fault! return 0; } gdb reveals that sizeof(double) evaluated to 0: > R_alloc (nelem=2, eltsize=0) at memory.c:1649 so it results in the segfault later. This is how I compile my

LLVM knows what all the types of the intrinsic functions are; I thought, why are users (including llvm-gcc...) required to duplicate all this information in order to use them? I mean in order to call getOrInsertFunction to get declarations for them. So I wrote this patch, which allows all this code to be generated automatically. Is this a good approach? Dan -- Dan Gohman, Cray Inc. <djg at

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 =

On Mon, 5 Feb 2007, Dan Gohman wrote: > LLVM knows what all the types of the intrinsic functions are; I thought, > why are users (including llvm-gcc...) required to duplicate all this > information in order to use them? I mean in order to call > getOrInsertFunction to get declarations for them. That is an excellent question! :) In the bad old days, we used to allow intrinsics

On Mon, Feb 05, 2007 at 12:28:56PM -0800, Chris Lattner wrote: > On Mon, 5 Feb 2007, Dan Gohman wrote: > > > LLVM knows what all the types of the intrinsic functions are; I thought, > > why are users (including llvm-gcc...) required to duplicate all this > > information in order to use them? I mean in order to call > > getOrInsertFunction to get declarations for

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

Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> writes: >> -----Original Message----- >> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of David Greene >> via llvm-dev >> Sent: Thursday, August 29, 2019 10:05 AM >> To: llvm-dev <llvm-dev at lists.llvm.org> >> Subject: [EXT] [llvm-dev] Complex proposal v2 >>

The current version of S_alloc in src/main/memory.c is char *S_alloc(long nelem, int eltsize) { unsigned int i, size; char *p = R_alloc(nelem, eltsize); for(i=0 ; i<size; i++) p[i] = 0; return p; } which segfaults because `size' is not initialized. I am not what the right fix is, adding size = nelem * eltsize; before the loop seems to work. As an aside ... I think the seed*

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

Hello all, I was playing with LLVM pass. I changed the lib/Transforms/Hello/Hello.cpp 's content to be my own pass. Then I make install the pass and use an example test1.c to see whether it works or not. When I run example using the following command: clang -emit-llvm test1.c -c -o test1.bc opt -load ../build_llvm/Debug+Asserts/lib/LLVMHello.so -hello < test1.bc > /dev/null It

Tanya, This patch at the end of this message is needed for Cygwin and GCC 4.2.x series. I also had to disable 'runtime/libprofile' by including the following in 'runtime/makefile' :- ifeq ($(OS), Cygwin) PARALLEL_DIRS := $(filter-out libprofile, $(PARALLEL_DIRS)) endif There maybe a better fix to make it work. Aaron ---------- Forwarded message ---------- From:

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

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

hacker cling wrote: > Hello all, > I was playing with LLVM pass. I changed the > lib/Transforms/Hello/Hello.cpp 's content to be my own pass. Then I make > install the pass and use an example test1.c to see whether it works or > not. When I run example using the following command: > clang -emit-llvm test1.c -c -o test1.bc > opt -load

Hello. I'm having difficulties getting R_alloc() to work. The test platform is a 64-bit Mac running R 2.2.1 installed via a .dmg file obtained from the R site. Details are given below, in a level of detail that I hope is appropriate. My eye was particularly drawn to line #2 in the gdb 'where' output, but line #1 seems sensible so I may just be displaying my ignorance by