On 26 March 2013 16:09, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:

On 03/26/2013 03:44 PM, Iain Buclaw wrote:
> This is why there are gdc-4.7, gdc-4.8 branches. They are there to be
> guaranteed to work with those gcc releases. There won't be any support for
> multiple gcc versions in one source.

I think you've misunderstood me (although I don't think I expressed myself well,
so mea culpa). I recognize the existence and purpose of the gcc-4.7 and gcc-4.8
branches and it makes perfect sense to organize things that way. It's just that
some remarks make it seem like new versions of the frontend will only be
guaranteed to work on 4.9.

Guaranteed is not the right word, but future releases of the frontend will be present only on 4.9. Though, people are free to backport to 4.8 or 4.7, as Johannes has done in the past.

I remember you discussing some work that would help to make it possible to just
pull in new versions of the frontend without any large re-working -- IIRC
replacing some direct calls to the DMD backend with a more generic API that
would be backend-agnostic -- and if there's in any case going to be some period
of instability due to switching to 4.9, I wonder if now might be the moment to
do that work?

See my pulls into DMD for a Target struct in the frontend. It's not complete, but it's slowly being pushed in.

The only expected instability will come from the planned removal of typinf.c, toobj.c, todt.c - which are to be replaced by a implementation that builds GCC trees directly.

--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';