search for: structtypeinfomap

...o 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 introduced it (was it Devang?). However, I agree with duncan: the right fix is to make the StructTypeInfoMap be indexed by a GCC type, not an llvm type. I am not fully familiar with how StructTypeInfoMap works, but I wouldn't be surprised if this caused other subtle miscompilations. -Chris

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

...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 introduced it (was it Devang?). Yup. PR 1278 > However, I agree with > duncan: the right fix is to make the StructTypeInfoMap be indexed by a > GCC type, not an llvm type. I am not fully familiar with how > StructTypeInfoMap works, but I wouldn't be surprised if this caused > other subtle miscompilations. > > -Chris > _______________________________________________ > LLVM Developers mailing list...

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. But, the second field is marked as Padding in the second