www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - align(n) not working as expected

reply %u <wfunction hotmail.com> writes:
Hi,

I'm not sure if I'm doing something wrong, but it seems like struct alignment
isn't really working. (I just found out that I'm not supposed to post this on
the digitalmars.D.bugs newsgroup, so I'm posting it here.)

When I execute this code:

 struct Temp
 {
  ubyte x;
  align(16) ubyte y;
 }
 auto o = Temp();
 std.stdio.writefln("Address of aligned fields: %#x, %#x", cast(size_t)&o.x,
cast(size_t)&o.y);

I get these addresses:
 0x18fd00, 0x18fd01
the second of which is not aligned on a 16-byte boundary.


Am I doing something wrong, or is this a bug?

Thank you!
Dec 27 2010
parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Tue, 28 Dec 2010 00:32:37 -0700, %u <wfunction hotmail.com> wrote:


 Hi,

 I'm not sure if I'm doing something wrong, but it seems like struct  
 alignment
 isn't really working. (I just found out that I'm not supposed to post  
 this on
 the digitalmars.D.bugs newsgroup, so I'm posting it here.)

 When I execute this code:

  struct Temp
  {
   ubyte x;
   align(16) ubyte y;
  }
  auto o = Temp();
  std.stdio.writefln("Address of aligned fields: %#x, %#x",  
 cast(size_t)&o.x,
 cast(size_t)&o.y);

 I get these addresses:
  0x18fd00, 0x18fd01
 the second of which is not aligned on a 16-byte boundary.


 Am I doing something wrong, or is this a bug?

 Thank you!


As per the docs, align behaves in the manner of the companion C++ compile.  
DMC only defines align(1) and align(4), so they're the only two that work.  
So this isn't a bug per say, but more than one of us has asked for  
align(8)/align(16) support. (or at least a compile time warning). But  
there's several technical/performance issues with maintaining alignment  
different from the underlying OS. I'd also recommend D.learn for questions  
like these.
Dec 27 2010
next sibling parent %u <wfunction hotmail.com> writes:
Interesting... I didn't know that only two are supported. Thank
you for the information!
Dec 28 2010
prev sibling next sibling parent reply "JimBob" <jim bob.com> writes:
"Robert Jacques" <sandford jhu.edu> wrote in message 
news:op.voeybap626stm6 sandford...

 On Tue, 28 Dec 2010 00:32:37 -0700, %u <wfunction hotmail.com> wrote:


 As per the docs, align behaves in the manner of the companion C++ compile. 
 DMC only defines align(1) and align(4), so they're the only two that work. 
 So this isn't a bug per say, but more than one of us has asked for 
 align(8)/align(16) support. (or at least a compile time warning). But 
 there's several technical/performance issues with maintaining alignment 
 different from the underlying OS. I'd also recommend D.learn for questions 
 like these.


The only issue is with stack variables. There's no reason not to have 
align(8) and align(16) for members. Heap alignment can be handled with a 
custom allocator.

It's just retarded to not have align(16) for members and yet have support 
for SSE asm instructions.

It's like telling someone yes the car has steering, but you have to use 
these two pieces of rope because we couldnt work out / afford power 
steering. The point being you could have put in un-powered steering for now 
at least.
Dec 28 2010
parent Don <nospam nospam.com> writes:
JimBob wrote:

 "Robert Jacques" <sandford jhu.edu> wrote in message 
 news:op.voeybap626stm6 sandford...

 On Tue, 28 Dec 2010 00:32:37 -0700, %u <wfunction hotmail.com> wrote:


 As per the docs, align behaves in the manner of the companion C++ compile. 
 DMC only defines align(1) and align(4), so they're the only two that work. 
 So this isn't a bug per say, but more than one of us has asked for 
 align(8)/align(16) support. (or at least a compile time warning). But 
 there's several technical/performance issues with maintaining alignment 
 different from the underlying OS. I'd also recommend D.learn for questions 
 like these.


 
 The only issue is with stack variables. There's no reason not to have 
 align(8) and align(16) for members. Heap alignment can be handled with a 
 custom allocator.
 
 It's just retarded to not have align(16) for members and yet have support 
 for SSE asm instructions.
 
 It's like telling someone yes the car has steering, but you have to use 
 these two pieces of rope because we couldnt work out / afford power 
 steering. The point being you could have put in un-powered steering for now 
 at least. 


Actually it's just a bug. It's recently been reported that align(n) is 
out by 4 for variables in thread local storage. Please report any other 
failures in bugzilla. align(16) should be respected for __gshared 
variables, at least.
Dec 28 2010
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 28/12/2010 07:41, Robert Jacques wrote:
<snip>

 As per the docs, align behaves in the manner of the companion C++
 compile. DMC only defines align(1) and align(4), so they're the only two
 that work.


<snip>

But what is meant to happen if an alignment the companion C compiler 
doesn't support is used?  I would think not just silently ignore it.

See also
http://www.digitalmars.com/d/archives/digitalmars/D/Spec_of_align_attribute_is_a_mess_88129.html

In fact, it's for a different reason that it doesn't work in this 
instance.  Consecutive byte members are always packed, regardless of the 
alignment setting.  Other members smaller than the alignment setting are 
packed in a similar way.  Try this at home:

struct Temp {
     ubyte x;
     align(16) cdouble y;
}
pragma(msg, Temp.y.offsetof);

and likewise for align values 1, 2, 4 and 8.

By my experiments, it seems the maximum alignment for a given type is:
- for primitive types except real and creal, the type's size
- for real and creal, 2
- for static arrays, the element type's maximum alignment
- for all reference types, 4 (presumably always the platform pointer size)
- for structs, the highest maximum alignment of any member

Of course, other compilers may do it differently.

Stewart.
Dec 28 2010