www.digitalmars.com         C & C++   DMDScript  

D.gnu - [Issue 2191] New: GDC fraudulently defines D_InlineAsmX86

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

           Summary: GDC fraudulently defines D_InlineAsmX86
           Product: DGCC aka GDC
           Version: 0.23
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Keywords: wrong-code
          Severity: blocker
          Priority: P1
         Component: glue layer
        AssignedTo: dvdfrdmn users.sf.net
        ReportedBy: clugdbug yahoo.com.au


Because GDC does not implement the D calling convention (issue 1805), inline
asm generally doesn't work for GDC. Valid D code results in bad code generation
and segfaults.
The workarounds for this are truly horrible.
Fortunately, the fix for this problem is simple: stop defining D_InlineAsmX86
until the D calling convention is supported. This should only require changes
to one line of code.
Optionally it could be changed to Gnu_InlineAsmX86.

I've ranked this as blocker, because I do not think that any library should
support GDC while this problem exists.

It would even be worth re-releasing the current version of GDC with no other
changes other than fixing this problem. It is the root cause of bugs such as



--
Jul 03 2008
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2191






I think this bug is invalid. The spec says about "the D_InlineAsmX86" version,
that is specifies that inline asm is supported.

Looking at the inline asm page, at the top it says "Differing D
implementations, however, are free to innovate upon the memory model, function
call/return conventions, argument passing conventions, etc.".

To me this means that the ABI documentation (which is mostly TDB anyway), is a
recommendation, not a requirement. As such I'd recommend a new version like
D_ABICompliant, or something.

I'm currently working on ABI conformance in LLVMDC for x86, hence my interest
in this ticket.

While I see the value of ABI conformance, in the case of LLVMDC, it can mean
(probably) significant performance decrease as we can no longer tell it to use
the 'fastest' calling convention for extern(D).


--
Aug 22 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2191








 I think this bug is invalid. The spec says about "the D_InlineAsmX86" version,
 that is specifies that inline asm is supported.
 
 Looking at the inline asm page, at the top it says "Differing D
 implementations, however, are free to innovate upon the memory model, function
 call/return conventions, argument passing conventions, etc.".


Read the previous paragraph. That means "different from Pentium". It does not
mean "different from DMD".

D_InlineAsmX86 _has_ to mean "inline X86 asm will work".


 To me this means that the ABI documentation (which is mostly TDB anyway), is a
 recommendation, not a requirement. As such I'd recommend a new version like
 D_ABICompliant, or something.
 
 I'm currently working on ABI conformance in LLVMDC for x86, hence my interest
 in this ticket.
 
 While I see the value of ABI conformance, in the case of LLVMDC, it can mean
 (probably) significant performance decrease as we can no longer tell it to use
 the 'fastest' calling convention for extern(D).


Differing ABIs are a catastrophe. They are one of the worst mistakes of C++. I
cannot stress this strongly enough. If you have a different ABI, you have a
different language. 

(It's really obvious in the case of inline asm, where you need to write
different asm code for every different calling convention).

Note, though, that the D ABI only applies to X86_32. Since nothing is defined
for X86-64, you're free to innovate. (For example, on AMD64, using XMM
registers
for parameter passing).


--
Aug 25 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2191






OK. I've had another look at this page, and I see your point now. Indeed I've
misread what it says. I guess I should get that version removed then :( 

Thanx for clearing this up for me.


--
Aug 25 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2191








 OK. I've had another look at this page, and I see your point now. Indeed I've
 misread what it says. I guess I should get that version removed then :( 


Thank you! Of course, we can still use inline asm with LLVMDC, just need to use
it for version(llvm) instead of version(D_InlineAsmX86).


 Thanx for clearing this up for me.


Actually I think it's worthy of a bug report for Walter -- the spec isn't as
clear as it could be. You're not the first person who's been confused by it. 


--
Aug 26 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2191






After a while working on this, I'll almost go as far as saying the ABI spec is
useless. It's contradictory, incomplete and well, just wrong. I can understand
David not wanting to spend time on implementing the D ABI... The only really
useful information is about how values are returned.


--
Sep 15 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2191




Just got a bump of this ticket in my inbox.

For an update from my part, as of
https://bitbucket.org/goshawk/gdc/changeset/8da0d2cf8366  GDC no longer emits
any of the D_InlineAsm family of identifiers by default, and GNU_InlineAsm is
defined.

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


Iain Buclaw <ibuclaw ubuntu.com> changed:

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



I think I was meant to close this ticket after the last comment.  There are no
plans to turning D_InlineAsm back on.  After some discussion a while ago, GCC
core devs are not too keen on adding another calling convention to i386 on top
of what's already there.

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