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