align(n) not working as expected

Don nospam at nospam.com
Tue Dec 28 13:01:36 PST 2010


JimBob wrote:
> "Robert Jacques" <sandford at jhu.edu> wrote in message 
> news:op.voeybap626stm6 at sandford...
>> On Tue, 28 Dec 2010 00:32:37 -0700, %u <wfunction at 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.


More information about the Digitalmars-d mailing list