llvm dev - Jun 2016 - [BUG] 3.8 alignment/struct padding

Hi,

I have what appears to be an alignment/struct padding bug. An i64 is not
correctly aligned to the 8-byte boundary, and this results in a mismatched
struct size between C and LLVM. We are currently running 3.8, and did not see
this bug in 3.5.

Please advise.

Ram

--
%int128m_T = type { [2 x i64] }
%cint32_T = type { i32, i32 }
%creal_T = type { double, double }

%struct0_T = type { float, double, [4 x i8], [4 x i16], [100 x i32], [6 x i64],
[64 x i64], [3 x i8], %creal_T, i32, i8, i16, %cint32_T, i32, [10 x %int128m_T],
double, double, double, i8, double, float }

In LLVM, the offsets are computed as:

struct0_T = {
float,               // 0
double,              // 8
[4 x i8],            // 16
[4 x i16],           // 20
[100 x i32],         // 28
[6 x i64],           // 428
[64 x i64],          // 476
[3 x i8],            // 988
%creal_T,            // 992
i32,                 // 1008
i8,                  // 1012
i16,                 // 1014
%cint32_T,           // 1016
i32,                 // 1024
[10 x %int128m_T],   // 1028
double,              // 1192
double,              // 1200
double,              // 1208
i8,                  // 1216
double,              // 1224
float                // 1232
}

The equivalent C struct:

typedef struct {
  real32_T s;
  real_T d;
  int8_T i8[4];
  uint16_T ui16[4];
  int32_T i32[100];
  uint64_T ui64[6];
  int64_T i64[64];
  char_T c[3];
  creal_T mycomplex;
  int32_T enumeration_int32;
  int8_T enumeration_int8;
  uint16_T enumeration_uint16;
  cint32_T fixedpoint;
  int32_T fixedpoint2;
  int128m_T fimw[10];
  real_T fisd1;
  real_T fisd2;
  real_T fisd3;
  int8_T fisb;
  real_T fid;
  real32_T fis;
} struct0_T;

In C the offsets are computed as:

8
16
20
28
432 << This was 428 in LLVM; 432 is divisible by 8, but 428 is not.
480
992
1000
1016
1020
1022
1024
1032
1040
1200
1208
1216
1224
1232
1240

On 28 June 2016 at 11:59, Ramkumar Ramachandra via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> I have what appears to be an alignment/struct padding bug. An i64 is not
> correctly aligned to the 8-byte boundary, and this results in a mismatched
> struct size between C and LLVM. We are currently running 3.8, and did not
see
> this bug in 3.5.
LLVM needs to be provided with a datalayout to calculate correct
struct offsets, and for historical reasons the default alignment
requirement for i64 is only 32-bits. I suspect you're just relying on
this default, you should be able to crib the correct layout from a
Clang-compiled C file and use Module::setDataLayout to fix it.

Cheers.

Tim.

Thanks Tim.

Cheers.
On Tue, Jun 28, 2016 at 3:07 PM Tim Northover <t.p.northover at gmail.com>
wrote:
> On 28 June 2016 at 11:59, Ramkumar Ramachandra via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > I have what appears to be an alignment/struct padding bug. An i64 is
not
> > correctly aligned to the 8-byte boundary, and this results in a
> mismatched
> > struct size between C and LLVM. We are currently running 3.8, and did
> not see
> > this bug in 3.5.
>
> LLVM needs to be provided with a datalayout to calculate correct
> struct offsets, and for historical reasons the default alignment
> requirement for i64 is only 32-bits. I suspect you're just relying on
> this default, you should be able to crib the correct layout from a
> Clang-compiled C file and use Module::setDataLayout to fix it.
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160630/68da2e16/attachment.html>