http://d.puremagic.com/issues/show_bug.cgi?id=231

           Summary: long is 4-byte aligned in unittest with 4 character
                    module name
           Product: D
           Version: 0.161
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Keywords: wrong-code
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: sean@f4.ca


This one is really weird.  It turns out that the value must be used in a unittest, etc, as per the test case, and the error actually goes away if I change the module name to be larger than 4 characters.  This is a new bug, as the test this is derived from used to pass without error:

C:\code\src\d\bugs>type 161x.d
template testStoreIf( T )
{
    void testStoreIf( T val = T.init + 1 )
    {
        T base;
        assert( atomicValueIsProperlyAligned!(T)( cast(size_t) &base ) );
    }
}
import std.c.stdio;

template atomicValueIsProperlyAligned( T )
{
    bool atomicValueIsProperlyAligned( size_t addr )
    {
        printf( "%p %% %u = %u\n", addr, T.sizeof, addr % T.sizeof );
        return addr % T.sizeof == 0;
    }
}


unittest
{
    testStoreIf!(long)();
}


void main()
{

}
C:\code\src\d\bugs>dmd -unittest 161x.d
C:\bin\dmd\bin\..\..\dm\bin\link.exe 161x,,,user32+kernel32/noi;

C:\code\src\d\bugs>161x
0012FEEC % 8 = 4
161x(6): Assertion failure

C:\code\src\d\bugs>copy 161x.d 161_1.d
        1 file(s) copied.

C:\code\src\d\bugs>dmd -unittest 161_1.d C:\bin\dmd\bin\..\..\dm\bin\link.exe 161_1,,,user32+kernel32/noi;

C:\code\src\d\bugs>161_1
0012FEE8 % 8 = 0

C:\code\src\d\bugs>


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=231





------- Comment #1 from sean@f4.ca  2006-06-29 13:26 -------
I just realized the real problem here is that I'm expecting longs to be 8-byte aligned on a system with no native 8-byte type.  Perhaps it's just dumb luck that I've never encountered a long whose address was not 8-byte aligned?  With that in mind, how does DMD align longs?  And is this portable across compilers?


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=231





------- Comment #2 from sean@f4.ca  2006-06-29 13:38 -------
One last update.  I just noticed that the static data segment is actually
different sizes for the two modules tested above.  The data segment for 161x is
68 bytes and is 72 bytes for 161_1.  It also seems weird that the size of a
module name should affect the stack location of a variable used in a unit test.
 In any case, here are the two data segments.  Notice the additional padding
before __ModuleInfo_5161_1 in the latter case:

168x:

_DATA   segment
        db      025h,070h,020h,025h,025h,020h,025h,075h
        db      020h,03dh,020h,025h,075h,00ah,000h,031h
        db      036h,031h,078h,000h
__ModuleInfo_4161x:
        db      000h,000h,000h,000h
        db      000h,000h,000h,000h,004h,000h,000h,000h
        dd      offset FLAT:_DATA[0Fh]
        db      000h,000h,000h,000h
        dd      offset FLAT:__ModuleInfo_4161x[030h]
        db      000h,000h,000h,000h
        db      000h,000h,000h,000h,000h,000h,000h,000h
        db      000h,000h,000h,000h,000h,000h,000h,000h
        dd      offset FLAT:__modtest_4161x
_DATA   ends

161_1:

_DATA   segment
        db      025h,070h,020h,025h,025h,020h,025h,075h
        db      020h,03dh,020h,025h,075h,00ah,000h,031h
        db      036h,031h,05fh,031h,000h,000h,000h,000h
__ModuleInfo_5161_1:
        db      000h,000h,000h,000h,000h,000h,000h,000h
        db      005h,000h,000h,000h
        dd      offset FLAT:_DATA[0Fh]
        db      000h,000h,000h,000h
        dd      offset FLAT:__ModuleInfo_5161_1[030h]
        db      000h,000h,000h,000h,000h,000h,000h,000h
        db      000h,000h,000h,000h,000h,000h,000h,000h
        db      000h,000h,000h,000h
        dd      offset FLAT:__modtest_5161_1
_DATA   ends


-- 

The length of the error messages might be making a difference.

"161x(6): Assertion failure"
"161_1(6): Assertion failure"

What was the last version that you tried it with? If it was pre 0.160 then the change to assert semantics might be causing this.

BCS wrote:
> The length of the error messages might be making a difference.
> 
> "161x(6): Assertion failure"
> "161_1(6): Assertion failure"
> 
> What was the last version that you tried it with? If it was pre 0.160 then the change to assert semantics might be causing this.

Good idea--it was pre-160.  I haven't unit tested this code for a while.

http://d.puremagic.com/issues/show_bug.cgi?id=231





------- Comment #3 from someidiot@earthlink.net  2006-06-29 14:21 -------
Seems like only FP-double has a problem being 32-bit aligned on the x86?


"On Pentium and PentiumPro, double and long double values should be aligned to an 8 byte boundary (see -malign-double) or suffer significant run time performance penalties. On Pentium III, the Streaming SIMD Extension (SSE) data type __m128 suffers similar penalties if it is not 16 byte aligned."


"On the Pentium and subsequent x86 processors, there is a substantial performance penalty if double-precision variables are not stored 8-byte aligned; a factor of two or more is not unusual. Unfortunately, the stack (the place that local variables and subroutine arguments live) is not guaranteed by the Intel ABI to be 8-byte aligned."


This would suggest 'double' should be correctly aligned on the stack (for
better performance). In particular, a double[] should be correctly aligned (on
the heap also) ?


-- 

> ------- Comment #3 from someidiot@earthlink.net  2006-06-29 14:21 -------
> Seems like only FP-double has a problem being 32-bit aligned on the x86?

For what it's worth, I altered the code to use a double instead of a long and the alignment issue existed there as well.

http://d.puremagic.com/issues/show_bug.cgi?id=231


bugzilla@digitalmars.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID




------- Comment #4 from bugzilla@digitalmars.com  2006-07-08 16:39 -------
Not a bug, since longs only need to be aligned on 4 byte boundaries on a 32 bit machine.


-- 

d-bugmail@puremagic.com wrote:
> http://d.puremagic.com/issues/show_bug.cgi?id=231
> 
> 
> bugzilla@digitalmars.com changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|NEW                         |RESOLVED
>          Resolution|                            |INVALID
> 
> 
> 
> 
> ------- Comment #4 from bugzilla@digitalmars.com  2006-07-08 16:39 -------
> Not a bug, since longs only need to be aligned on 4 byte boundaries on a 32 bit
> machine.

Thanks.  Out of curiosity, does this apply to double as well?  I noticed the same issue there.


Sean

d-bugmail@puremagic.com wrote:
> http://d.puremagic.com/issues/show_bug.cgi?id=231
> 
> 
> bugzilla@digitalmars.com changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|NEW                         |RESOLVED
>          Resolution|                            |INVALID
> 
> 
> 
> 
> ------- Comment #4 from bugzilla@digitalmars.com  2006-07-08 16:39 -------
> Not a bug, since longs only need to be aligned on 4 byte boundaries on a 32 bit
> machine.
> 
> 

It's apparently well known that doubles need to be 64-bit aligned on x86 devices. Otherwise, the performance is known to drop by a factor of two or more. I suspect you'd agree that's quite significant?

Does D align double on 32bit or 64bit? How about double[] ?