On 27 June 2012 16:47, Joseph S. Myers <jos...@codesourcery.com> wrote: > On Wed, 27 Jun 2012, Iain Buclaw wrote: > >> It's copied as including c-common.c / .h causes problems with a fair >> number of references pulled in that need to be stubbed out - also, >> some GCC function attributes that we use do not make any sense to have >> in D code (eg: gnu_inline, artificial, cleanup). It could certainly >> be possible though ... Will need to review this in more detail. > > Quite possibly you need to split up c-common so that the parts that can > also be shared with D are in separate files. > >> The D frontend is completely independent of the GCC backend, and any >> alterations are purely for portability (eg, the use of real_t rather >> than long double for the representation of floats). There is no > > If for portability, I'd hope they wouldn't need to be conditional - > rather, the common repository used for all the compilers using the > dfrontend code should be able to have them, unconditionally, and another > such compiler might have a typedef of real_t to long double if that's what > that other compiler wishes to use. Hopefully you can work with the people > maintaining other such compilers so that there can genuinely be a shared, > portable source base for the shared code, in a public repository used by > all those maintainers, without conditionals based on which compiler it's > used in, and with that shared source base only using an absolute minimum > of headers from whatever compiler it's used in (so only minimal GCC > headers when used in GCC, etc.). >
In some ways, some elements of the code is already shared, and I've have no trouble sending patches for GDC-specific elements provided that they are wrapped around #ifdef IN_GCC. >> Likewise, have removed it as is in fact no longer required. The >> "optimize" #undef remains for the time being as it conflicts with the >> name of a member in the D frontend sources. If the D frontend >> followed the C++ Coding Conventions as outlined in >> gcc.gnu.org/wiki/CppConventions then this wouldn't be an issue. >> Though I don't think it has an obligation to being essentially >> disconnected from calling any GCC code. > > But it ought to be possible to stop the shared D front end from including > the relevant GCC headers at all, if it has a clean interface to the rest > of GCC.... > It's the other way round, actually. It's the GDC code that errors on compilation from including the main header (mars.h) in the D frontend. The dfrontend code does not touch d-gcc-includes.h, and I can add in a compile #error to assert that is always the case now that I'm using IN_GCC_FRONTEND to build the GDC sources. >> Have removed all alloca handling from GDC and replaced with simply >> including libiberty.h. > > system.h includes libiberty.h, so direct inclusion of libiberty.h > shouldn't be needed (unless you are trying to avoid using system.h in code > shared with other D compilers). > I'd rather not be including headers in GCC into the D frontend, however useful they may be. One reason for this is that system.h poisons at least one function that the D frontend uses (strdup in rmem.c). Although I'm sure the maintainers would be happy to accept any patches I send if the D frontend must be compliant and not use these banned functions in GCC. >> https://github.com/D-Programming-GDC/GDC/commits/master >> >> >> I do have a question though, what is available for the transition of >> development from git to svn? Other than a lot of ready and getting >> used to the various switches and commands on my part. > > Once there is a front end ready to commit and approved in technical and > GNU policy terms, you'd just do "svn add" on the files to add them to > trunk. It's up to you how you handle keeping the dfrontend/ changes in > sync with an external shared repository (with all changes going to the > external repository first); Ian Taylor may have some automation for that > issue for Go. > OK, thanks. As the D frontend goes through a sometimes experimental development process between each release, I'd rather have it so that I merge the frontend into GDC as each release happens, instead of keeping in constant sync. This is how I handle such merges at the moment, although it doesn't help if you require a track of all changes made to the D frontend. Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
