[Issue 8583] [64 bit] AA ushort[dchar] byValue range is corrupted on x86_64

[d-bugmail at puremagic.com]

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


Simon Harris <pearfalse at googlemail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pearfalse at googlemail.com


--- Comment #4 from Simon Harris <pearfalse at googlemail.com> 2013-01-16 07:37:10 PST ---
Something interesting I found in rt/aaA.d, line 106: aligntsize() on 64-bit
compilation returns a value aligned to 16 bytes. _aaGetX uses this function on
key sizes when creating new elements. So for AAs whose key is <= 8 bytes, the
value is still 16 bytes further on in memory.

You can check this by repeating the same alignment trick on the addresses of
byValue.front:

void testAAType(K, V)(V[K] aa)
{
    writefln("testAAType with key %s, value %s", typeid(K), typeid(V));

    for (auto v = aa.byValue; !v.empty; v.popFront()) { // emulated foreach (v
; aa.byValue)
        V* fp = &v.front();
        writef("Unaligned: <%s>", *fp);

        V* fpaligned = cast(V*) (( (cast(ptrdiff_t) fp) + 15) & ~15); // copy
what aligntsize does on x64

        version(D_LP64) {
            writefln("; Aligned: <%s>", *fp.alignto16());
        }
        else {
            writefln(" (Not testing aligned value on a 32-bit executable)");
        }
    }
}

Looking at the key sizes seems to match the pass/fail results in comment #2,
with one exception: ushort[uint[3]]. Not sure why the alignment trick is needed
here, given that uint[3].sizeof > 8. Maybe DMD aligns
AssociativeArray!(uint[3], ushort).Slot to 4 bytes to save space, and since
_aaGetX uses a completely different type set, alignment info gets lost
somewhere.

Tested with DMD 2.060 and 2.061 on OS X 10.8.2.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------