On 20 June 2012 14:01, Joseph Rushton Wakeling <[email protected]> wrote: > On 19/06/12 19:19, Iain Buclaw wrote: >> >> Had round one of the code review process, so I'm going to post the main >> issues >> here that most affect D users / the platforms they want to run on / the >> compiler >> version they want to use. > > > A somewhat different take on these issues -- we've several times now had > discussions over the backend of DMD, and the whole "reference implementation > not entirely free/open source" issue. One of the points made in those > discussions is that the issue is somewhat moot given that the real > "reference implementation" is the frontend, and this already has at least 2 > free backends (GCC and LLVM). > > However, that point stops being moot the moment there are compiler-specific > constraints that mean that code that will compile with DMD won't compile > with GDC, or vice-versa. If I can't use inline asm with GDC, or I have to > go about it in a different way to DMD, then we can hardly say that GDC > reflects the reference implementation. > > It seems to me that guaranteeing equal capabilities between DMD and GDC > should be a "red line" in determining what changes or deletions are > acceptable or not.
Unfortunately this is a red line I am going to cross. Haven't yet pushed anything yet, but feel free to visualise: I have altered the following to the gdc build for all gdc-specific sources (which includes d inline assembler implementation) - GCC system headers are included first and foremost before all other headers. - Now compiles with macro -DIN_GCC_FRONTEND turned on Result: GDC now fails to compile as we pull in many middle-end and backend headers that have been POISONED for GCC frontends to use. Apparently I somehow bypassed this. :o) Fix: Remove all included headers that are poisoned - but wait! - now D inline assembler is missing crucial key elements of what made it just about work in GDC. Hands are tied, sorry. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
