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



--- Comment #10 from John Colvin <john.loughran.colvin@gmail.com> 2013-04-21 19:56:15 BST ---
(In reply to comment #9)
> (In reply to comment #7)
> > I'm pretty sure the use of void[] in _memset128ii is simply so as to have a 128bit data type. It's never used as, or expected to be, an array.
> > 
> > _memset128ii doesn't care whether it's being passed a static or dynamic array, it just blindly increments a pointer and writes to it "count" times.
> 
> I think it does matter whether dynamic array was passed or a static one due to how arguments are passed.

It doesn't matter in this case because it is a pointer being passed, not an array at all.

> > (In reply to comment #3)
> > > _memset128ii expects:
> > > 
> > > %rcx => size_t count
> > > %rdx => .ptr of value array
> > > $rsi => .length of value array
> > > %rdi => pointer to first argument array
> > 
> > This is incorrect. _memset128 expects:
> > 
> > RCX: size_t count
> > RDX: higher 64 bits of value
> > RSI: lower 64 bits of value
> > RDI: pointer to the 1st element of the destination array.
> 
> I see no difference between length dynamic array property and your "lower 64 bits of value" (also between ptr and "higher 64 bits of value").

because value is not an array. As I said before, void[] is just used because
conveniently void[].sizeof == 16 (128 bits) on x64 (the check for x64 is done
inside e2ir.c)

> And passing a
> pointer to dynamic array is not the same thing as passing pointer to the first
> element: http://dpaste.dzfl.pl/8f91aed8

See my comment above. Each *element* of the array is being represented by a void[]. There is no D style array passing happening here, static or otherwise, it's just pointers.

Imagine replacing void[] with a hypothetical _128BitType and you'll see what I mean.

I'm currently re-implementing memset.d and updating the compiler to interact with the new functions. This should hopefully fix this bug and maybe 9969 also, if there isn't a nasty backend bug hiding behind it all.

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

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



--- Comment #11 from John Colvin <john.loughran.colvin@gmail.com> 2013-04-21 20:11:09 BST ---
(In reply to comment #10)
> There is no D style array passing happening here, static or otherwise, it's just pointers.

Sorry, mistake.

There is an array being passed as "value", but from the callers point of view (generated in dmd) it's not an array at all, it's just a 128 bit type.

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

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



--- Comment #12 from Maxim Fomin <maxim@maxim-fomin.ru> 2013-04-22 09:44:52 PDT ---
(In reply to comment #10)
> > I see no difference between length dynamic array property and your "lower 64 bits of value" (also between ptr and "higher 64 bits of value").
> 
> because value is not an array. As I said before, void[] is just used because
> conveniently void[].sizeof == 16 (128 bits) on x64 (the check for x64 is done
> inside e2ir.c)

Value is actually accepted as an array due to passing conversions and unusual usage inside memset function is no excuse for changing ABI interpretation. Clearly, anyone can pass many different things through some inappropriate parameter but it does not mean that each time callee would adjust passing convention for different types. I don't see point in this dispute further . I argue that value is technically accepted as dynamic array and you argue that it is treated as 128 bit element. These points don't contradict and however arguments are called (lower value or length property) does change the picture - there is no correspondence between what is passed and what is received.

> I'm currently re-implementing memset.d and updating the compiler to interact with the new functions. This should hopefully fix this bug and maybe 9969 also, if there isn't a nasty backend bug hiding behind it all.

I doubt that it is possible without dmd hacking but good luck.

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

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


Ali Cehreli <acehreli@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |acehreli@yahoo.com


--- Comment #13 from Ali Cehreli <acehreli@yahoo.com> 2013-10-26 11:30:17 PDT ---
I hit the same bug without any obvious SIMD operations:

struct Point
{
    double f;
    double g;
}

void main()
{
    Point[1] arr;
}

Ali

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