Difference between revisions of "GDC/GCCSubmission"

From D Wiki
Jump to: navigation, search
(Patch Approval Status)
m (Patch Approval Status)
Line 15: Line 15:
 
  | [https://gcc.gnu.org/ml/gcc-patches/2017-05/msg02122.html v1] [https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00932.html v4]
 
  | [https://gcc.gnu.org/ml/gcc-patches/2017-05/msg02122.html v1] [https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00932.html v4]
 
  | The front-end (DMD) language implementation and license.
 
  | The front-end (DMD) language implementation and license.
  | [https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00582.html Under Review] (FSF approved for inclusion)
+
  | [https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00582.html Under Review] (FSF approved)
 
  |-
 
  |-
 
  | 002
 
  | 002

Revision as of 17:58, 18 September 2018


Since the initial submission of the D front-end to GCC, this aims to keep a record of the current status of both policy and technical review.


Patch Approval Status

Patch Number Patch Version Patch Description Status
001 v1 v4 The front-end (DMD) language implementation and license. Under Review (FSF approved)
002 v2 v4 The front-end (GDC) implementation. Under Review (v2)
003 v2 v4 The front-end (GDC) changelogs. Approved (v2)
004 v2 v4 The front-end (GDC) config, makefile, and manpages. Under Review (v2)
005 v1 v4 GCC configuration file changes and documentation. Assume Approved (v2)
006 v2 v4 Add D language support to GCC proper. Assume Approved (v2)
007 v2 v4 Add D language support to GCC targets. Pending
008 v1 v4 D2 Testsuite tests. Assume Self Approved (v4)
009 v2 v4 D2 Testsuite Dejagnu files. Approved (v2)
010 v4 GDC Testsuite files Assume Self Approved (v4)
011 v1 v4 The D runtime library and license. Under Review (v2)
012 v2 v4 GCC builtins and runtime support (part of D runtime) Assume Approved (v2)
013 v1 v4 The Phobos runtime library and license. Pending
014 v2 v4 Phobos config, makefiles, and testsuite. Pending

Change Requests Status

Change Request Change Status Change Notes
GCC steering committee approval of accepting the FE contribution and appointing a FE maintainer. Done
Does this stuff get bound into GCC? The reason I ask is the files are under the Boost license with ownership by Digital Mars. While we often have a fair amount of leeway with runtime systems, we may not have the same kind of license/ownership leeway with things that are actually part of the compiler itself. Did the discussions between the FSF, Digital Mars and Walter touch in these issues at all? Have you received any guidance from the parties on this issue? Done Contacted Richard Stallman, there is no problem with including the DMD sources as-is (now copyright D Language Foundation). Same goes for the D runtime and Phobos libraries.
Create a GDC svn/git branch on GCC for platform integration testing. Proposal Requires approval of the SC.
GCC-specific files in D runtime (gcc.builtins, etc) should have the GCC Runtime Library Exception notice. Done GDC#493
There appear to be various GPLv2 notices with old FSF addresses. Where those are on source files (as opposed to generated files), they should be updated to the usual GPLv3+ notice for GCC. Done GDC#493, GDC#495
DMD front end has functions with names such as error, but no useful i18n will actually occur because GDC formats the messages with xvasprintf before passing to the common diagnostic code. The DMD front end should be disabled, to prevent exgettext from extracting and putting messages in gcc.pot that won't actually be translated. Done
  • Add DMD sources to list of sources disabled for translation, GDC#499
  • Improve GDC diagnostic to use diagnostic_report_diagnostic() directly, GDC#497
Target::critsecsize should have its code belonging to the gcc/config/ configuration for each target as a target hook returning the required information, not in the D front end code. Done
  • See list of changes required to implement. GDC#500
  • For the worst case (unsupported target), should set the target hook to default to returning a large enough buffer size, e.g: 64.
Note we recently allowed generation of the dependency files even in the case some errors. Please consider doing the same if it makes sense. See the Sept change to c_common_finish. Suggestion Haven't looked into it.
How important are the environment variables to the existing user base? We generally try to avoid changing much behavior based on environment variables. Can these be made command line options? Done DDOCFILE and D_IMPORT_PATH were undocumented and removed. GDC#619
You probably want to review the #ifdefs you've got in here to make sure they're not supposed to be checked via #if or runtime checks (there's only a half-dozen or so): STACK_GROWS_DOWNWARD, HAVE_LD_STATIC_DYNAMIC, HAVE_LD_STATIC_DYNAMIC, BIGGEST_FIELD_ALIGNMENT, ADJUST_FIELD_ALIGN, ENABLE_TREE_CHECKING. Done Checked, and all are legitimate apart from ENABLE_TREE_CHECKING. GDC#530

Other Maintenance Tasks

Change Request Change Status Change Notes
Create a dmd-cxx git branch on dlang/dmd to host GDC's forked C++ front end sources. Done
  • Create a new branch based on dmd/2.068
  • Merge all changes during 2.069 development up until the switch-over.
  • Merge or cherry-pick in backports that have been applied on the GDC branch.
Add gdc devs to MAINTAINERS. Pending. Patch submitted for self.