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



--- Comment #19 from Leandro Lucarella <leandro.lucarella@sociomantic.com> 2012-05-31 04:29:21 PDT ---
Just a simple example (I've used to see if the progress on the bug fixed some of the problems I had :):

---
extern (C)
{
    struct lldiv_t
    {
        long quot,
             rem;
    }
    lldiv_t lldiv(long numer, long denom);
    int printf(char* fmt, ...);
}

void main(char[][] args)
{
    auto r = lldiv(94, 82);
    printf("%lld %lld\n", r.quot, r.rem);
}
---

For me, returns a high, randomish (changes on each run) number and 3 or 1.
Examples:
20967488 3
32686144 3
38604832 1
20029472 1

-- 
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=5570



--- Comment #20 from Walter Bright <bugzilla@digitalmars.com> 2012-05-31 12:39:49 PDT ---
(In reply to comment #19)
> Just a simple example (I've used to see if the progress on the bug fixed some of the problems I had :):
> 
> ---
> extern (C)
> {
>     struct lldiv_t
>     {
>         long quot,
>              rem;
>     }

The current state only fixes things that fit in one register. The lldiv_t is a two register struct.

-- 
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=5570


klickverbot <code@klickverbot.at> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code@klickverbot.at


--- Comment #21 from klickverbot <code@klickverbot.at> 2012-06-17 14:50:19 PDT ---
When fixing the remaining issues, please also consider treating dynamic D
arrays as »struct Array(T) { T* ptr; size_t length; }« on x86_64, i.e. passing
them in two integer registers (if available).

This is what GDC and LDC are doing right now, since always passing them on the stack, like DMD does right now, would require quite a lot of extra effort in resp. additions to the respective backend code.

There currently is a »pass on the stack for efficiency« comment in TypeDArray::toArgTypes(), but I can't quite see why this should be true in the general case, to be honest.

-- 
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=5570



--- Comment #22 from klickverbot <code@klickverbot.at> 2012-06-20 09:25:24 PDT ---
(In reply to comment #21)
> When fixing the remaining issues, please also consider treating dynamic D
> arrays as »struct Array(T) { T* ptr; size_t length; }« on x86_64, i.e. passing
> them in two integer registers (if available).

The fields of the struct should obviously have been swapped.

In any case, this has been addressed in
https://github.com/D-Programming-Language/dmd/commit/f50a339b86d9d2c141061d38f4f682211c3c07c3
and related commits – whether this was a coincidence or not, thanks a lot for
the quick fix!

--- Comment #23 from klickverbot <code@klickverbot.at> 2012-06-20 09:25:25 PDT ---
(In reply to comment #21)
> When fixing the remaining issues, please also consider treating dynamic D
> arrays as »struct Array(T) { T* ptr; size_t length; }« on x86_64, i.e. passing
> them in two integer registers (if available).

The fields of the struct should obviously have been swapped.

In any case, this has been addressed in
https://github.com/D-Programming-Language/dmd/commit/f50a339b86d9d2c141061d38f4f682211c3c07c3
and related commits – whether this was a coincidence or not, thanks a lot for
the quick fix!

-- 
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=5570



--- Comment #22 from klickverbot <code@klickverbot.at> 2012-06-20 09:25:24 PDT ---
(In reply to comment #21)
> When fixing the remaining issues, please also consider treating dynamic D
> arrays as »struct Array(T) { T* ptr; size_t length; }« on x86_64, i.e. passing
> them in two integer registers (if available).

The fields of the struct should obviously have been swapped.

In any case, this has been addressed in
https://github.com/D-Programming-Language/dmd/commit/f50a339b86d9d2c141061d38f4f682211c3c07c3
and related commits – whether this was a coincidence or not, thanks a lot for
the quick fix!

--- Comment #23 from klickverbot <code@klickverbot.at> 2012-06-20 09:25:25 PDT ---
(In reply to comment #21)
> When fixing the remaining issues, please also consider treating dynamic D
> arrays as »struct Array(T) { T* ptr; size_t length; }« on x86_64, i.e. passing
> them in two integer registers (if available).

The fields of the struct should obviously have been swapped.

In any case, this has been addressed in
https://github.com/D-Programming-Language/dmd/commit/f50a339b86d9d2c141061d38f4f682211c3c07c3
and related commits – whether this was a coincidence or not, thanks a lot for
the quick fix!

-- 
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=5570


Fawzi Mohamed <fawzi@gmx.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fawzi@gmx.ch


--- Comment #24 from Fawzi Mohamed <fawzi@gmx.ch> 2012-06-25 05:03:48 PDT ---
see Bug 8294, for something probably related with the work being done here...

-- 
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=5570



--- Comment #25 from klickverbot <code@klickverbot.at> 2012-06-26 04:48:42 PDT ---
Sigh – seems like I was not exactly right about how GDC and LDC are handling arrays. Instead of treating them like the equivalent struct, they are treated as if length and pointer were two separate arguments, with the important difference of course being that with the x86_64 ABI, structs are never only partly passed in registers (i.e., if there is only one register left, they would still pass the length in it and only push the pointer on the stack).

The LDC x86_64 ABI implementation has had the following explanatory comment since it was originally written in 2009:

> This helps make things like printf("%.*s", o.toString()) work as expected; if we didn't do this that wouldn't work if there were 4 other integer/pointer arguments before the toString() call because the string got bumped to memory with one integer register still free.

Changing the implementation to treat dynamic arrays/delegates the same as two-element structs for a potentially easier implementation of va_arg, etc. wouldn't be a problem, but we need to make a decision and, most importantly, properly document the expected behavior on dlang.org.

-- 
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=5570


Iain Buclaw <ibuclaw@ubuntu.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ibuclaw@ubuntu.com


--- Comment #26 from Iain Buclaw <ibuclaw@ubuntu.com> 2012-06-26 07:16:09 PDT ---
(In reply to comment #25)
> Sigh – seems like I was not exactly right about how GDC and LDC are handling arrays. Instead of treating them like the equivalent struct, they are treated as if length and pointer were two separate arguments, with the important difference of course being that with the x86_64 ABI, structs are never only partly passed in registers (i.e., if there is only one register left, they would still pass the length in it and only push the pointer on the stack).
> 

They are created as a two field struct in GDC.

eg, delegates (D arrays are a little above) https://github.com/D-Programming-GDC/GDC/blob/master/gcc/d/d-glue.cc#L3801

which calls: https://github.com/D-Programming-GDC/GDC/blob/master/gcc/d/d-codegen.cc#L1514


> The LDC x86_64 ABI implementation has had the following explanatory comment since it was originally written in 2009:
> 
> > This helps make things like printf("%.*s", o.toString()) work as expected; if we didn't do this that wouldn't work if there were 4 other integer/pointer arguments before the toString() call because the string got bumped to memory with one integer register still free.
> 

"%*.s" works purely out of coincidence.  You should not rely on it working at all - and if you are, you should really instead be fixing your program.


Regards
Iain

-- 
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=5570



--- Comment #27 from klickverbot <code@klickverbot.at> 2012-06-26 09:33:02 PDT ---
(In reply to comment #26)
> (In reply to comment #25)
> > Sigh – seems like I was not exactly right about how GDC and LDC are handling arrays. Instead of treating them like the equivalent struct, they are treated as if length and pointer were two separate arguments […]
> They are created as a two field struct in GDC.

Oh well, apparently GDC handles dynamic arrays like structs in most cases, but as size_t/void* pairs for variadic arguments, ABI-wise – I discovered this behavior looking at the generated assembly while working on the LDC vararg ABI, and didn't expect formal arguments to be treated differently. Maybe the behavior should be unified?

> "%*.s" works purely out of coincidence.  You should not rely on it working at all - and if you are, you should really instead be fixing your program.

It does _not_ work only out of coincidence with LDC, as the ABI it is using was apparently explicitly designed by Frits to support this, judging from the comment I quoted before. It's platform-dependent, yes, but guaranteed to work – with GDC/LDC, that is, as this official ABI docs don't specify any details for passing array arguments. I suppose this was done to support code which assumes x86 behavior.

In any case, I can't see much value in having it like this, and would certainly find just treating dynamic arrays as structs more natural. I just wanted to highlight that this needs to be discussed and probably documented.

-- 
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=5570



--- Comment #28 from Walter Bright <bugzilla@digitalmars.com> 2012-06-26 11:19:22 PDT ---
My intention is to have the following all behave the same way:

   delegate

   struct S { void*, void* }

   void*[2]

for parameter passing. The same goes for dynamic arrays. That means if you wrap a type in a struct, it will still pass the same way.

The idea of making %.*s work with strings (without using .length and .ptr) has been deprecated for a long time, it isn't worth it.

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