D2 Blockers?

[Iain Buclaw]

== Quote from Jordi (jordi at rovira.cat)'s article
> On 09/20/2010 08:48 PM, Iain Buclaw wrote:
> > == Quote from Jordi (jordi at rovira.cat)'s article
> >> On 08/18/2010 03:07 AM, dsimcha wrote:
> >>> == Quote from Iain Buclaw (ibuclaw at ubuntu.com)'s article
> >>>> Current developments that are taking priority first (in order) are:
> >>>> * Updating/Uploading packages in Debian and Ubuntu - as of writing, package
> >>>> is currently being built in Debian, with a predicted success across all 14
> >>>> supported architectures.>:-)
> >>>> * Port GDC to GCC-4.4 - nearly done, with one or two show-stoppers remaining
> >>>> with static chain decls and exprs.
> >>>> * Sort out the outstanding merges of D 1.062 and 1.063 - which somewhere
> >>>> along the line lost 64bit support. !!! - barely even started looking into it
> >>>> yet.
> >>>> Current blockers that need to be organised out (in my opinion) before D2 can
> >>>> be emerged are:
> >>>> * Integration into current GCC patches, which will require a regeneration of
> >>>> _all_ patches in the patch directory (even those I cannot account for as
> >>>> working).
> >>>> * Figuring out what internals need to be migrated from the current phobos2
> >>>> directory, what needs to keep.
> >>>> * A general consensus needs to be reached on how we should handle ASM
> >>>> version specifiers. Gnu_InlineAsmX86? D_InlineAsmX86? 64bit? Sort out* A
> > general consensus needs to be reached on how we should handle ASM version
> >>>> calling conventions?
> >>>> * GDC Driver updates to tie the whole thing together - the easy bit. ;-)
> >>>> Anything I missed? Should I be pushing D2 further up the stack of my list of
> >>>> TODOs?
> >>>> Regards
> >>>
> >>> It's tough to say where D2 support should be prioritized relative to
packaging, D1
> >>> fixes, general infrastructure improvements, etc.  My biased opinion (since I
> >>> personally don't use D1 and have tons of code written for the latest versions of
> >>> D2) is that getting a basically-working D2.048 compiler is by far the highest
> >>> priority.  I personally (definitely NOT speaking for the rest of the community)
> >>> have no use whatsoever for a D compiler that doesn't work with code written for
> >>> DMD 2.048.  However, I'm sure D1 users would beg to differ.  I guess it really
> >>> comes down to the ratio of D1 users to D2 users.>  >
> >>
> >> I just wanted to drop a small note to say i totally agree with dsimcha
> >> on prioritizing the version upgrades for gdc for d2. This would really
> >> strengthen D in general.
> >
> > I think it's pretty safe to say now that all other priorities I gave mention to a
> > month ago have been done and dusted. I've switched all my builds to D2 (so you
> > could say that I'm solely working on it now), and druntime is getting on a little
> > bit better with non-i386 architectures - having removed/replaced most problematic
> > code. Thanks to everyone who's been giving me feedback on that.
> >
> > I suppose the next step is to get on with the next frontend merge, 2.021. Though
> > admittedly it wouldn't have taken this long if the changes weren't so
breaking. ;-)
> >
> Sound great. If i were to help on this, what would be the easiest task
> to do? I guess merging revisions of druntime and phobos should be easier
> than dmd itself, as they might have less modifications.
> Actually i have tried merging with a 3-way merge tool the druntime in
> 2.020 and 2.021 with the current gdc and it didn't seem complicated.
> What do you use for testing it? dstress?
> j.

Dstress is the only testsuite to use currently, yes. It can take a long while
though to run through. Preferably we'd have our own testsuite using dejagnu, but I
haven't yet gotten down to work out how Expect works yet.

Unfortunately, there is no easy change going from 2.020 -> 2.021, because the
'this' parameter to struct member functions is now a reference type, rather than a
pointer (breaks all code implementations).

Because of this change, gdc will also ICE in quite a few locations for varying
reasons...

Help on fixing the codegen to adapt for 2.021 would help greatly, though would
require diving in the deep end of GCC internals.

Regards
Iain