similar to: [LLVMdev] an llvm-gcc bug

Hi Dale, > Here's a cute bug in llvm-gcc's struct translation: > > struct S242 { char * a;int b[1]; } ; > struct S93 { __attribute__((aligned (8))) void * a; } ; > > The second example is padded out to 8 bytes, so both of these look like > { i8 *, [1 x i32] } > This leads the "struct type factory" StructType::get to think they are > the same. >

On Feb 15, 2008, at 11:17 AM, Devang Patel wrote: > > On Feb 15, 2008, at 10:27 AM, Chris Lattner wrote: > >> >> On Feb 15, 2008, at 10:23 AM, Devang Patel wrote: >> >>> >>> On Feb 15, 2008, at 10:08 AM, Chris Lattner wrote: >>> >>>>>> Alternatively I can take the Padding bit into account in the >>>>>>

On Feb 15, 2008, at 10:27 AM, Chris Lattner wrote: > > On Feb 15, 2008, at 10:23 AM, Devang Patel wrote: > >> >> On Feb 15, 2008, at 10:08 AM, Chris Lattner wrote: >> >>>>> Alternatively I can take the Padding bit into account in the >>>>> StructType::get code somehow. Anyone have a strong opinion? >>>> >>>>

Dear LLVMers OK, when I signed up for this mailing list, I asked for a once-daily digest. This is the fourth digest I receive today, and there are about that many each day. The only reason I subscribe to the mailing list is so I can post to it. But I don't need to receive the emails, because I can fully well read them in the archive online, and I certainly don't want to get spammed

On Feb 15, 2008, at 11:22 AM, Dale Johannesen wrote: > > On Feb 15, 2008, at 11:17 AM, Devang Patel wrote: > >> >> On Feb 15, 2008, at 10:27 AM, Chris Lattner wrote: >> >>> >>> On Feb 15, 2008, at 10:23 AM, Devang Patel wrote: >>> >>>> >>>> On Feb 15, 2008, at 10:08 AM, Chris Lattner wrote: >>>>

>> Alternatively I can take the Padding bit into account in the >> StructType::get code somehow. Anyone have a strong opinion? > > Shouldn't it be a map from the gcc type to the padding info? > That said, you can get rid of the padding info as far as I'm > concerned. However Chris might have a different opinion - I > think he introduced it. I don't think I

On Feb 15, 2008, at 10:23 AM, Devang Patel wrote: > > On Feb 15, 2008, at 10:08 AM, Chris Lattner wrote: > >>>> Alternatively I can take the Padding bit into account in the >>>> StructType::get code somehow. Anyone have a strong opinion? >>> >>> Shouldn't it be a map from the gcc type to the padding info? >>> That said, you can get

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

Here's issue 48. I'm guessing I'm going to get issue 49 as soon as I hit send... On Fri, Feb 15, 2008 at 3:28 PM, <llvmdev-request at cs.uiuc.edu> wrote: > Send LLVMdev mailing list submissions to > llvmdev at cs.uiuc.edu > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > or, via

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, I am trying to read the "credit.lisp" file of the Japanese credit database in UCI repository, but it is in lisp format which I do not know how to read. I have not found how to do that in the foreign library http://archive.ics.uci.edu/ml/datasets/Japanese+Credit+Screening <http://archive.ics.uci.edu/ml/datasets/Japanese+Credit+Screening> Could anyone help me? Best

On Dec 6, 2006, at 1:58 PM, Andrew Lenharth wrote: > The attached patch (gcc.patch) implements the gcc portion of packed > types. I have only tested this on a few examples, so I may be missing > some type conversions somewhere. > > The gcc patch requires llvm_extra.patch, not included in the > previous emails. > > Andrew > <llvm_extra.patch> llvm_extra.patch

The attached patch (gcc.patch) implements the gcc portion of packed types. I have only tested this on a few examples, so I may be missing some type conversions somewhere. The gcc patch requires llvm_extra.patch, not included in the previous emails. Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm_extra.patch Type: text/x-patch Size: 1677 bytes

On Feb 16, 2008, at 11:32 AM, Evan Cheng wrote: > But I am using llvm-gcc-4.2. Any idea why it's failing? > > Evan All the failing testers are using gcc-4.0 according to the web pages they point at. > On Feb 16, 2008, at 11:24 AM, Dale Johannesen wrote: > >> On Feb 16, 2008, at 7:06 AM, Apache wrote: >>> New Test Failures: >>>

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 Sat, 2011-10-29 at 15:16 -0500, Hal Finkel wrote: > On Sat, 2011-10-29 at 14:02 -0500, Hal Finkel wrote: > > On Sat, 2011-10-29 at 12:30 -0500, Hal Finkel wrote: > > > Ralf, et al., > > > > > > Attached is the latest version of my autovectorization patch. llvmdev > > > has been CC'd (as had been suggested to me); this e-mail contains > >

On Feb 15, 2008, at 10:08 AM, Chris Lattner wrote: >>> Alternatively I can take the Padding bit into account in the >>> StructType::get code somehow. Anyone have a strong opinion? >> >> Shouldn't it be a map from the gcc type to the padding info? >> That said, you can get rid of the padding info as far as I'm >> concerned. However Chris might

Dear All, I’m working on a project that extends C. I’m adding a new type of pointer that is a fat pointer. It has some metadata about the pointed object besides the starting address of the object. Currently I implemented this pointer as an llvm:StructType. In llvm::Type generation function llvm::Type *CodeGenTypes::ConvertType(QualType T) in the case for clang::Type::Pointer, instead of creating

On Sat, 2011-10-29 at 14:02 -0500, Hal Finkel wrote: > On Sat, 2011-10-29 at 12:30 -0500, Hal Finkel wrote: > > Ralf, et al., > > > > Attached is the latest version of my autovectorization patch. llvmdev > > has been CC'd (as had been suggested to me); this e-mail contains > > additional benchmark results. > > > > First, these are preliminary

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