On 05/28/2017 03:11 PM, Iain Buclaw wrote: > This patch adds the D front-end implementation, the only part of the > compiler that interacts with GCC directly, and being the parts that I > maintain, is something that I can talk about more directly. > > For the actual code generation pass, that converts the front-end AST > to GCC trees, most parts use a separate Visitor interfaces to do a > certain kind of lowering, for instance, types.cc builds *_TYPE trees > from AST Type's. The Visitor class is part of the DMD front-end, and > is defined in dfrontend/visitor.h. > > There are also a few interfaces which have their headers in the DMD > frontend, but are implemented here because they do something that > requires knowledge of the GCC backend (d-target.cc), does something > that may not be portable, or differ between D compilers > (d-frontend.cc) or are a thin wrapper around something that is managed > by GCC (d-diagnostic.cc). > > Many high level operations result in generation of calls to D runtime > library functions (runtime.def), all with require some kind of runtime > type information (typeinfo.cc). The compiler also generates functions > for registering/deregistering compiled modules with the D runtime > library (modules.cc). > > As well as the D language having it's own built-in functions > (intrinsics.cc), we also expose GCC builtins to D code via a > `gcc.builtins' module (d-builtins.cc), and give special treatment to a > number of UDAs that could be applied to functions (d-attribs.cc). > > > That is roughly the high level jist of how things are currently organized. > > Regards > Iain > > --- > Presumably the types and interfaces which are capitalized in violation of GNU standards are done so to interface the the DMD implementation?
Which implies the answer to a question in my prior message, namely that the DMD implementation does get linked into GCC itself. So I think we need the SC to rule on whether or not that's allowed. I'm not going to dive deep into this code -- it's essentially converting between the different representations and is code that you'd be maintaining. 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): +#ifdef STACK_GROWS_DOWNWARD +#ifdef HAVE_LD_STATIC_DYNAMIC +#ifdef HAVE_LD_STATIC_DYNAMIC +#ifdef BIGGEST_FIELD_ALIGNMENT +#ifdef ADJUST_FIELD_ALIGN +#ifdef ENABLE_TREE_CHECKING Joseph already commented on Target::critsecsize. Jeff Jeff
