Is tr1 array supposed to be 16 byte aligned?

Question

In "gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)" in tr1 array, I see this:

  value_type _M_instance[_Nm ? _Nm : 1] __attribute__((__aligned__));

whereas in "gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4)", I see this:

  value_type _M_instance[_Nm ? _Nm : 1];

that is, it seems that tr1 arrays are no longer specified as aligned (which affects SSE code written for them). Some of our unit tests are failing in _mm_load_ps. Is there discussion of this change anywhere?

They'll be aligned for `value_type`. If you need anything beyond that, you have to add it yourself. Note that this isn't part of any standard and a pure compiler-specific problem. — Kerrek SB, Jan 04 '12 at 02:25

score 0 · Accepted Answer · edited May 23 '17 at 10:08

The specification doesn't specify that tr1::array is 16-byte aligned. The only guarantee is that the array will be aligned properly according to the size of value_type. Unless the sizes of objects that you are storing in the arrays are such that value_type alignment is a multiple of 16 bytes, then you will not get the 128-bit alignment that you desire to use SSE instructions. If you have existing code that relies upon the fact that one compiler used 16-byte alignment for all array instances, then you should fix it. You're taking advantage of behavior that is in excess of what the standard defines, which is very fragile.

If you have code that relies upon a specific amount of alignment on the memory that it uses, then you should explicitly enforce that alignment when you allocate the memory; anything less is prone to errors if you change compilers or platforms. A previous question addresses how to make tr1::array objects use aligned memory.

Is tr1 array supposed to be 16 byte aligned?

1 Answers1