Difference between revisions of "LDC"

From D Wiki
Jump to: navigation, search
(Useful Links: #d -> #ldc)
m (Update status LDC on PowerPC)
Line 44: Line 44:
 
=== PowerPC 64-bit ===
 
=== PowerPC 64-bit ===
  
* Requires LLVM trunk because of [http://llvm.org/bugs/show_bug.cgi?id=14751 PR14751], [http://llvm.org/bugs/show_bug.cgi?id=14779 PR14779], [http://llvm.org/bugs/show_bug.cgi?id=15347 PR15347] and [http://llvm.org/bugs/show_bug.cgi?id=15359 PR15359]. A solution for [http://llvm.org/bugs/show_bug.cgi?id=15580 PR15580] is currently missing (blocks linking of Dwarf debug symbols). Atomic stores results in bus errors if used with other types then ulong ([http://llvm.org/bugs/show_bug.cgi?id=15630 PR15630]).
+
* Requires LLVM trunk because of [http://llvm.org/bugs/show_bug.cgi?id=14751 PR14751], [http://llvm.org/bugs/show_bug.cgi?id=14779 PR14779], [http://llvm.org/bugs/show_bug.cgi?id=15347 PR15347] and [http://llvm.org/bugs/show_bug.cgi?id=15359 PR15359]. A solution for [http://llvm.org/bugs/show_bug.cgi?id=15580 PR15580] is currently missing (blocks linking of Dwarf debug symbols). Atomic stores results in bus errors if used with other types then ulong ([http://llvm.org/bugs/show_bug.cgi?id=15630 PR15630]). Additionally, there is still a problem with PPC128 doubles ([http://llvm.org/bugs/show_bug.cgi?id=15632 PR15632]).
 
* Only Linux because LLVM does not cleanly compile on AIX.
 
* Only Linux because LLVM does not cleanly compile on AIX.
 
* Code generation is known to work.
 
* Code generation is known to work.
Line 51: Line 51:
 
** phobos: Changes in std.math are required
 
** phobos: Changes in std.math are required
 
** Other modules seem to be fine
 
** Other modules seem to be fine
* Roughly 80% of the test suite passes. These are some modules with problems (incomplete):
+
* 90% of the test suite passes - only 98 tests feil. These are some modules with problems (incomplete):
 
** Unit test failures: core.math, core.demangle, core.thread, object, std.complex, std.uri, std.regexp, std.datetime (debug only), std.md5, std.file, std.bitmanip, std.outbuffer, std.csv, std.math
 
** Unit test failures: core.math, core.demangle, core.thread, object, std.complex, std.uri, std.regexp, std.datetime (debug only), std.md5, std.file, std.bitmanip, std.outbuffer, std.csv, std.math
 
** Seg faults: core.atomic (debug only), std.container (release only with -O3), std.traits, std.datetime (release only)
 
** Seg faults: core.atomic (debug only), std.container (release only with -O3), std.traits, std.datetime (release only)

Revision as of 00:14, 1 April 2013

Compilers: OverviewDMDGDCLDC

The LDC project aims to provide a portable D programming language compiler with modern optimization and code generation capabilities. The compiler uses the official DMD frontends to support the latest D2 version, and relies on the LLVM Core libraries for code generation.

LDC is fully Open Source; the parts of the code not taken/adapted from other projects are BSD-licensed (see the LICENSE file for details).

D1 is no longer supported in the current development tree; the last version supporting it can be found at the d1 Git branch.

Getting started

Project status

In general, LDC should work fine on most x86/x86-64 Unix-like systems, including Linux, OS X 10.7+ and most BSD flavors. Code generation should work for other platforms supported by the LLVM MC codegen infrastructure (for example ARM), but druntime/Phobos support will most likely be lacking.

OS X version prior to 10.7 (Lion) are currently not supported by the D2 compiler, because LLVM's support for thread-local storage depends on functionality which first appeared in 10.7.

x86 Windows using MinGW

  • LDC 2 from Git master compiles and builds druntime/Phobos, but requires applying patches to LLVM and the MinGW runtime to fix some bugs. See Building LDC on MinGW x86.
  • Hello World-style programs work (including TLS and exception handling).
  • A small number of remaining test cases still fails, but many of the harder issues (real math precision, MS C runtime-caused problems, ABI differences) have already been solved.
  • Estimate for making Windows x86/MinGW a »first class« target: 1 weekend of focused work, plus a Windows CI slave.

x86-64 Windows using MSVC

  • LDC/LDC2 from master branch compiles without patches.
  • See Building and hacking LDC on Windows using MSVC for detailed instructions.
  • LLVM 3.1 is required (3.0 does not work because of missing TLS support); LLVM 3.2/3.3 is preferred.
  • druntime and Phobos compile but linker errors are still possible.
  • Exception handling still needs work (see here for a first patch; the llvm-objdump part of the patch is here and was commited in LLVM 3.3)
  • Contact: kai@redstar.de

ARM

  • Code generation is known to work.
  • Currently blocked by PR15293
  • Some initial work has been done on druntime, but support is not yet complete – see issue #116.

PowerPC 64-bit

  • Requires LLVM trunk because of PR14751, PR14779, PR15347 and PR15359. A solution for PR15580 is currently missing (blocks linking of Dwarf debug symbols). Atomic stores results in bus errors if used with other types then ulong (PR15630). Additionally, there is still a problem with PPC128 doubles (PR15632).
  • Only Linux because LLVM does not cleanly compile on AIX.
  • Code generation is known to work.
  • Issues in druntime and phobos:
    • druntime: Compiles cleanly but I expect more changes in core.thread
    • phobos: Changes in std.math are required
    • Other modules seem to be fine
  • 90% of the test suite passes - only 98 tests feil. These are some modules with problems (incomplete):
    • Unit test failures: core.math, core.demangle, core.thread, object, std.complex, std.uri, std.regexp, std.datetime (debug only), std.md5, std.file, std.bitmanip, std.outbuffer, std.csv, std.math
    • Seg faults: core.atomic (debug only), std.container (release only with -O3), std.traits, std.datetime (release only)
    • Reason for failures are likely: math precision, thread synchronisation, frontend bugs, endian issues, bad code generation, ...
  • Contact: kai@redstar.de

Contributing

LDC is an entirely community-driven effort, so all contributions are warmly welcomed. The easiest way to help with development is to write high-quality bug reports for any issues you run into. For a quick guide on what a useful report should contain, please see Reporting LDC issues.

If you are interested in getting into compiler development, anecdotal evidence suggests that hacking on LDC might be a nice first step, particularly because the LLVM backend is very comfortable to work with. To get started, just browse through the issue list, find a ticket that tickles your fancy (some of them are specifically marked as "junior jobs"), and work on a fix – and of course don't hesitate to ask for advice at the mailing list or on IRC. An LDC contributor's guide is in the works.

We would also be excited to see LDC packages in more OS distributions, particular Debian and its derivatives. So, if you think you might be able to help, please just drop us a line at the development mailing list. We will actively try to make packaging as smooth as possible, but besides the fact that upstream-maintained packages are sometimes discouraged, it is hard to build good packages for a system you don't know well, so we need to rely on external contributors here.

Useful Links