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
#1230, and many workarounds in Tango.


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





------- Comment #1 from tomas famolsen.dk  2008-08-22 11:38 -------
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





------- Comment #2 from clugdbug yahoo.com.au  2008-08-25 02:26 -------
(In reply to comment #1)
 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





------- Comment #3 from tomas famolsen.dk  2008-08-25 09:30 -------
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





------- Comment #4 from clugdbug yahoo.com.au  2008-08-26 03:56 -------
(In reply to comment #3)
 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 parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2191





------- Comment #5 from tomas famolsen.dk  2008-09-15 09:28 -------
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