== Quote from Jordi (jo...@rovira.cat)'s article > On 09/20/2010 08:48 PM, Iain Buclaw wrote: > > == Quote from Jordi (jo...@rovira.cat)'s article > >> On 08/18/2010 03:07 AM, dsimcha wrote: > >>> == Quote from Iain Buclaw (ibuc...@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
