www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 5570] New: 64 bit C ABI not followed for passing structs and complex numbers as function parameters

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5570

           Summary: 64 bit C ABI not followed for passing structs and
                    complex numbers as function parameters
           Product: D
           Version: D1 & D2
          Platform: x86_64
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: bugzilla digitalmars.com


--- Comment #0 from Walter Bright <bugzilla digitalmars.com> 2011-02-13
15:08:20 PST ---
They are always pushed on the stack rather than sometimes being passed in
registers. Haven't got to fixing this yet.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 13 2011
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5570


Leandro Lucarella <llucax gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
                 CC|                            |llucax gmail.com
           Severity|normal                      |critical


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5570



--- Comment #1 from Leandro Lucarella <llucax gmail.com> 2011-12-16 04:20:00
PST ---
Any ETA for a fix?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5570


Mathias Baumann <mathias.baumann sociomantic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mathias.baumann sociomantic
                   |                            |.com


--- Comment #2 from Mathias Baumann <mathias.baumann sociomantic.com>
2011-12-16 06:13:08 PST ---
This bug prevents us from switching to 64bit. We really would appreciate a fix.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5570


Damian Ziemba <nazriel6969 gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nazriel6969 gmail.com


--- Comment #3 from Damian Ziemba <nazriel6969 gmail.com> 2011-12-16 06:45:46
PST ---
Because of this bug, you can not use wxD with DMD64.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5570


siegelords_abode yahoo.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |siegelords_abode yahoo.com


--- Comment #4 from siegelords_abode yahoo.com 2011-12-17 11:49:28 PST ---
See also http://d.puremagic.com/issues/show_bug.cgi?id=6348. It's plain
impossible to use C libraries with value semantics for structs on 64 bits.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 17 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5570


Trass3r <mrmocool gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mrmocool gmx.de


--- Comment #5 from Trass3r <mrmocool gmx.de> 2012-02-01 17:08:14 CET ---
So should we raise this to 'blocker'?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 01 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5570


Graham <grahamc001uk yahoo.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |grahamc001uk yahoo.co.uk


--- Comment #6 from Graham <grahamc001uk yahoo.co.uk> 2012-02-01 14:42:02 PST
---
Issue 6772 http://d.puremagic.com/issues/show_bug.cgi?id=6772
"Cannot pass cfloat argument type to a function on x86_64" is related or
possible duplicate.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 01 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5570


Nick Sabalausky <cbkbbejeap mailinator.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cbkbbejeap mailinator.com
           Severity|critical                    |blocker


--- Comment #7 from Nick Sabalausky <cbkbbejeap mailinator.com> 2012-04-09
22:12:13 PDT ---
"So should we raise this to 'blocker'?"

I would argue "yes" since the *only* way to work around it if you can't modify
the C side is to just not use 64-bit D. So it is a blocker for 64-bit D. (And
AIUI, not all 64-bit systems are multilib, so even switching to 32 isn't always
going to be an option.) Plus, there's...how many people *right here* have
identified it as blocking them?

Fuck, I'm just going to go ahead and raise it to blocker. If anyone has a
problem with that they can change it back. Either way, the important thing is
for this to get fixed, not to worry about its proper classification. So I don't
know why I even wrote all this...Oh well... ;)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 09 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5570


Mihail Strashun <m.strashun gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |m.strashun gmail.com


--- Comment #8 from Mihail Strashun <m.strashun gmail.com> 2012-04-10 06:04:56
PDT ---
If bug preventing almost any x64 D code interconnecting with C libs is not a
blocker, I can hardly imagine what is.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 10 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5570


Jonathan M Davis <jmdavisProg gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg gmx.com


--- Comment #9 from Jonathan M Davis <jmdavisProg gmx.com> 2012-04-10 10:11:53
PDT ---

  If bug preventing almost any x64 D code interconnecting with C libs is not a
 blocker, I can hardly imagine what is.


I don't know how Walter decides that sort of thing or how he treats blockers. I
believe that the worse that we normally see is critical. But this is something
which has _never_ worked, and it's in a newer feature - 64-bit code generation
- and it's something that not everyone is using. So, something which was in D
itself (as opposed to how it talks with C code) which used to work but doesn't
now could certainly be more of a blocker than this, depending on what it was.
But in general, 64-bit specific stuff is less critical in that it only affects
those using 64-bit rather than _everyone_ like many bugs do.

I would actually expect Walter to consider this critical rather than a blocker.
Certainly, if blocker indicates that something should block a release, this
isn't it, since the bug has been around for as long as dmd's 64-bit code
generation has been. But that's up to him.

Regardless, this is a huge issue, and it should probably be treated as a higher
priority than it has been, but much of what _has_ been being worked on is high
priority stuff which affects much more D code than this does, so I suppose that
it's not all that surprising that Walter hasn't gotten around to this yet.
Still, I'd hope that this would be taken care of sooner rather than later.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 10 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5570



--- Comment #10 from Mihail Strashun <m.strashun gmail.com> 2012-04-11 04:23:31
PDT ---
(In reply to comment #9)

 So, something which was in D
 itself (as opposed to how it talks with C code) which used to work but doesn't
 now could certainly be more of a blocker than this,


My point exactly is that interfacing to C broken at ABI level is much more
important than any inside language issue. Regressions are more important, yes,
but, well, there is an importance level "regression" before "blocker" exactly
for them. I'd say it is in the same category as "wrong code generation" for
basic language constructs. It is something you rarely expect from even the new
language when facing problems, something rather hard to identify and something
almost any desktop D user is doomed to meet when try to build something usable
( as most usable programs tend to involve C bindings at this stage of std lib
).

Issue a warning that it can happen when compiling extern(C) stuff of x64 at
least.

tl;dr : it is really bad for marketing

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 11 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5570



--- Comment #11 from Jonathan M Davis <jmdavisProg gmx.com> 2012-04-11 09:51:04
PDT ---
In general, something which has never worked is going to be treated as less of
a priority than something which worked before and doesn't now - _especially_
when it's part of a newer feature. And this has _never_ worked correctly. And I
don't know why you would think that a C ABI issue would be more important than
an issue in D itself. As bad as this is, most D code is completely unaffected
by this. It's only once you start dealing with C and structs that it matters.

Now, why Walter hasn't this considered a high enough priority to fix it yet, I
don't know. This is clearly a serious bug, and I would have thought that he
would have made it a fairly high priority once he figured out that it was a
problem, but for whatever reason, he hasn't. There are plenty of other high
priority issues that he's been working on though - many of which have been
around much longer than this. Still, one would hope that this wouldn't languish
much longer. It's a major impedement to using 64-bit on D projects.

By the way, for those that this is actually preventing from using 64-bit dmd
and who really need it, gdc probably doesn't have this problem, since it
relates to code generation. So, you could try that while waiting for Walter to
get around to this.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 11 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5570


Leandro Lucarella <leandro.lucarella sociomantic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |http://d.puremagic.com/issu
                   |                            |es/show_bug.cgi?id=6772


--- Comment #12 from Leandro Lucarella <leandro.lucarella sociomantic.com>
2012-04-16 03:27:08 PDT ---
(In reply to comment #11)

 In general, something which has never worked is going to be treated as less of
 a priority than something which worked before and doesn't now - _especially_
 when it's part of a newer feature.


Yeah, and you know that something that worked before and doesn't work now is
exactly what's called a *regression*, which have higher priority than
*blocker*.

So we all agree on that :)


 And this has _never_ worked correctly. And I 
 don't know why you would think that a C ABI issue would be more important than
 an issue in D itself. As bad as this is, most D code is completely unaffected
 by this. It's only once you start dealing with C and structs that it matters.


And that is a lot of codebase, you know? For example wxD, as Damian Ziemba
pointed out can't work without this fixed. Also, and probably much less
important than wxD, is making life at the company I work a little miserable
trying to migrate to 64bit with this bug around. AFAIK Walter cares about big
projects as wxD and making D usable for companies to consider this bug a
blocker when it really blocks that kind of uses.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 16 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5570


Johan Hernandez <thepumpkin1979 gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thepumpkin1979 gmail.com


--- Comment #13 from Johan Hernandez <thepumpkin1979 gmail.com> 2012-04-25
11:19:32 PDT ---
This is definitely a blocker, please fix this, this is a huge issue on OSX too.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 25 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5570


James Miller <james aatch.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |james aatch.net


--- Comment #14 from James Miller <james aatch.net> 2012-05-03 01:13:16 PDT ---
Throwing my vote in for this one, this is pretty much stopping me from using
DMD64 for my C bindings. For the record, LDC works in this case.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 03 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5570



--- Comment #15 from github-bugzilla puremagic.com 2012-05-07 12:29:35 PDT ---
Commit pushed to dmd-1.x at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/246f737c0f246f0b89ee27bfb611965e64f611ac
start on fixing issue 5570 64 bit ABI

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 07 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5570



--- Comment #15 from github-bugzilla puremagic.com 2012-05-07 12:29:35 PDT ---
Commit pushed to dmd-1.x at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/246f737c0f246f0b89ee27bfb611965e64f611ac
start on fixing issue 5570 64 bit ABI

--- Comment #16 from github-bugzilla puremagic.com 2012-05-07 12:29:45 PDT ---
Commit pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/f1039b341f2798f176dcf3c34019682d413ea863
start on fixing issue 5570 64 bit ABI

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 07 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5570



--- Comment #17 from Johan Hernandez <thepumpkin1979 gmail.com> 2012-05-07
12:40:48 PDT ---
I'm very happy to see some commits on this issue, this is really important!!!
Walter++!!!

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 07 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5570


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug yahoo.com.au


--- Comment #18 from Don <clugdbug yahoo.com.au> 2012-05-23 01:18:18 PDT ---
Another commit towards this issue:

https://github.com/D-Programming-Language/dmd/commit/29eb972a2f329276a72a19e722671ff26bfe8534

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 23 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
May 31 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
May 31 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jun 17 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jun 20 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jun 20 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jun 25 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jun 26 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jun 26 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jun 26 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jun 26 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5570



--- Comment #29 from Iain Buclaw <ibuclaw ubuntu.com> 2012-06-27 10:02:08 PDT
---
(In reply to comment #27)

 (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?
 


Yes, that is correct for dynamic arrays. :~)

It does it on a condition that's pre-set as 'true' and can't be altered by the
user.  Of course, if all two field types in D (D arrays; delegates) should
*always* be passed in the same way as two field struct should be, then I can
turn it off (and add a switch to toggle it), or remove this code.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 27 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5570



--- Comment #30 from Don <clugdbug yahoo.com.au> 2012-07-30 02:01:12 PDT ---
Progress at DMD1.075/2.060 beta2:
This now works for structs which contain integral types only, or which contain
floating point types only. It doesn't work if you have an int member and a
float member.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 30 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5570


Adrian Matoga <epi atari8.info> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |epi atari8.info


--- Comment #31 from Adrian Matoga <epi atari8.info> 2012-10-12 23:32:04 PDT ---
*** Issue 8810 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 12 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5570


Andrej Mitrovic <andrej.mitrovich gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrej.mitrovich gmail.com


--- Comment #32 from Andrej Mitrovic <andrej.mitrovich gmail.com> 2012-10-22
12:47:53 PDT ---
(In reply to comment #30)

 Progress at DMD1.075/2.060 beta2:
 This now works for structs which contain integral types only, or which contain
 floating point types only. It doesn't work if you have an int member and a
 float member.


http://dpaste.dzfl.pl/f1ac00d2

Output is Test(5, 6, 5, 6) instead of Test(5, 6, 7, 8). It works OK if the
function is extern(C).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 22 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5570



--- Comment #33 from David Nadlinger <code klickverbot.at> 2012-12-29 18:04:07
PST ---
I added issue 9239 as a blocker of this, as it also concerns the System V
x86-64 ABI.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 29 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5570


Marco Leise <Marco.Leise gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Marco.Leise gmx.de


--- Comment #34 from Marco Leise <Marco.Leise gmx.de> 2013-02-06 03:59:36 PST
---
Is this why my XCB calls on Linux fail? I already accused XCB people of writing
incorrect tutorials until I realized that the exact same code does work in C.
After probably two hours of trial and error to fix my code and reading articles
on the web the word x86-64 showed up there and I had a dim memory of something
not working in DMD 64-bit and C structs. So I tried GDC again, which I stopped
because it produced another error somewhere else. There it works. The struct I
try to get returned by a C library function looks like this:

struct { void*, int, int }

Most notably the int fields in my case should be 116 and 1, but are 0 and 0,
while the pointer does have some value (not sure if the correct one as they
change from executable to executable).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 06 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5570



--- Comment #35 from github-bugzilla puremagic.com 2013-02-23 15:10:03 PST ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/8fbb9279d51605d74824789d4954477b714bef52
64 bit ABI struct returns - Issue 5570 again

https://github.com/D-Programming-Language/dmd/commit/a39da1070a5dbc84ecc1cd509ea85634ffdd7081
Merge pull request #1630 from Govelius/8fbb9279d51605d74824789d4954477b714bef52

64 bit ABI 16byte struct returns - Issue 5570 again

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 23 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5570



--- Comment #36 from github-bugzilla puremagic.com 2013-02-25 10:38:47 PST ---
Commit pushed to dmd-1.x at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/b2da13f39701796a6934e200f7c024305bd0c9e8
Merge pull request #1630 from Govelius/8fbb9279d51605d74824789d4954477b714bef52

64 bit ABI 16byte struct returns - Issue 5570 again

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 25 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5570


Martin Nowak <code dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code dawg.eu


--- Comment #37 from Martin Nowak <code dawg.eu> 2013-06-06 13:18:21 PDT ---
Is this finally finished?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 06 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5570



--- Comment #38 from David Nadlinger <code klickverbot.at> 2013-06-06 13:20:26
PDT ---
I don't think the three byte struct issue (see linked bug) has been fixed yet,
but I haven't checked in a while.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 06 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5570


thelastmammoth gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thelastmammoth gmail.com


--- Comment #39 from thelastmammoth gmail.com 2013-09-21 19:48:09 PDT ---
(In reply to comment #38)

 I don't think the three byte struct issue (see linked bug) has been fixed yet,
 but I haven't checked in a while.


has not been fixed. was going to submit a bug report until I saw this thread.

problem with:

struct VideoMode{
    uint width;
    uint height;
    uint bitsPerPixel;
}
sfWindow* sfWindow_create(sfVideoMode mode, const(char)* title, uint style,
const(ContextSettings)* settings);

This is used in SFML-D https://github.com/krzat/SFML-D, making it unsable on
osx 64bit: the sample program crashes with auto screen = new
RenderWindow(VideoMode(800, 600), "Game", WindowStyle.Default, null); which I
believe is caused by this. 

This leads to a lot of duplication, for example the authors had to duplicate c
bindings just to address this:
https://github.com/Jebbs/DSFML-C where they point to this bug.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 21 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5570



--- Comment #40 from Andrej Mitrovic <andrej.mitrovich gmail.com> 2013-09-22
02:47:30 PDT ---
(In reply to comment #39)

 This leads to a lot of duplication, for example the authors had to duplicate c
 bindings just to address this:
 https://github.com/Jebbs/DSFML-C where they point to this bug.


I wonder if as a workaround you could type the prototypes in D as:

// note the .tupleof
sfWindow* sfWindow_create(VideoMode.tupleof mode, const(char)* title, uint
style, const(ContextSettings)* settings);

And then call it via:

VideoMode vm;
sfWindow_create(vm.tupleof, ...);

I'd assume this would then properly use the stack? It's worth trying out to
avoid any new code duplication, and then when 5570 is finally fixed all you
have to do in user code is to remove ".tupleof" in the calls.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 22 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5570



--- Comment #41 from thelastmammoth gmail.com 2013-09-22 20:07:53 PDT ---
(In reply to comment #40)

 (In reply to comment #39)

 This leads to a lot of duplication, for example the authors had to duplicate c
 bindings just to address this:
 https://github.com/Jebbs/DSFML-C where they point to this bug.


 
 I wonder if as a workaround you could type the prototypes in D as:
 
 // note the .tupleof
 sfWindow* sfWindow_create(VideoMode.tupleof mode, const(char)* title, uint
 style, const(ContextSettings)* settings);



corrected that to sfWindow_create(typeof(VideoMode.tupleof), ...)


 
 And then call it via:
 
 VideoMode vm;
 sfWindow_create(vm.tupleof, ...);


still segfaults


 
 I'd assume this would then properly use the stack? It's worth trying out to
 avoid any new code duplication, and then when 5570 is finally fixed all you
 have to do in user code is to remove ".tupleof" in the calls.



so far my (sad) woraround is to add a new C function that takes a pointer to
the struct, and link against it.

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