GDC/ProjectIdeas

This is a list of project ideas for GDC - potential improvements, new features, et cetera. As well as a list of ongoing projects going on within GDC.

Fix known bugs

• There are lots of bugs in bugzilla. Everyone is welcome to look at them, reproduce them, comment on them, fix them, etc!

• There are testsuite failures running 'make check-d' on many systems. Each one of these failures should be investigated, and either fixed or the testsuite adjusted. See the autotester results for more details on some of the regularly tested platforms, however other platforms should start being well tested too!

• There are a number of XBUG markers in testsuite. Some of them are for bugs in GDC that no one has looked at in a long time. There should be fewer!

Periodic Tasks

• Merge the d/dfrontend sources with upstream DMD releases.

• Merge the libphobos/libdruntime sources with upstream Druntime releases.

• Merge the libphobos/src sources with upstream Phobos releases.

• Create a release branch and test building GDC with each GCC release.

• Update the latest development branch of GDC to be continually in sync with latest GCC development changes.

General

(These listed are mixed active/idle stuff that needs more explanation of what's going on!)

• Merging GDC into upstream GCC.

• Porting D to ARM.

• Porting D to MinGW.

• Improve GDB with a more complete D debugging support.

• Implement DEH chaining support (as documented in TDPL?)

• GCC LTO support is broken horribly, any attempt to use LTO will result in ICE'ing the LTO compiler.

• Maybe convert DMD-style IASM routines to GDC-style EASM.

• Support all variants of --enable-threads= and --enable-tls in the GC.

• Remove dependency on _tlsstart and _tlsend symbols from within the library/compiler.

• Implement shared library support. The current implementation upstream is unsupported / not merged into GDC.

• Update GDC's gcc.atomic from using GCC's __sync builtins to __atomic, update mappings to core.atomic module.

Documentation

• The documentation in d/README is inadequately little, and contains references to old changes that are no where else to be found. This should be improved, and old documentation archived on the wiki.

• Missing d/NEWS and d/CONTRIBUTE documentation.

• There is documentation on wiki4d that needs moving and updating to somewhere more easily accessible.

• The GDC manpage d/gdc.texi could be better written.

• GDC Extended Assembler needs better documentation with multiple examples, such as that found in LDP for GCC.

Internals

• d/d-asmstmt.cc

• This file implements the ExtAsmStatement class that handles GCC-style inline assembler may be a problem as is non-standard to the D frontend.
• It also currently does not handle the ability to jump to D labels via a fifth section after the clobber list contains a list of all labels to which the assembly may jump (ie: Just like __asm__ goto in GCC).

• The only supported GDC-style @attribute's are "noinline", "forceinline", "flatten", and "target". This may need extending as seen fit.

• d/d-dmd-gcc.h

• This header is the only glue header used by the D frontend, this implements GDC-specific function hooks that call the GCC backend / performs platform agnostic tasks while the frontend is still in its semantic stages. This header should not really exist, and all functions be moved to a common header (ie: target.h) shared between compiler backends.

• The macros IN_GCC and GCC_SAFE_DMD which are used to conditionally compile code in the frontend to work against GDC and its backend should be gradually removed from the D frontend, and either made into a runtime hook (ie: target.h, port.h, etc), or GDC (or DMD) should be fixed to handle the discrepancy between compiler backends.

• d/lang.opt

• Remove -fsplit-dynamic-arrays code-gen switch and clean-up expand_intrinsic; d_build_call; etc...

Maintenance

• There are bug reports for GDC scattered over the place. The documented place to raise bugs are in the GDC Bugzilla, however some are in D's bugzilla, and some are older bugs are in Bitbucket Issue Tracker. These should all be moved into one place for ease of tracking.

• MinGW downloads should be hosted elsewhere.

• To be considered as a project part of GCC, the code in GDC should ideally conform to coding standards of GCC. This should be fixed up in all areas of the code - whatever standard the D frontend or Phobos uses from upstream is not a concern.

• The configure and makefiles as part of libgphobos / libgdruntime should be cleaned up and improved to handle more targets and compilation scenarios (ie: Are Canadian-crosses even supported?).