From d-bugmail at puremagic.com Wed Sep 1 11:25:45 2010 From: d-bugmail at puremagic.com (d-bugmail at puremagic.com) Date: Wed, 1 Sep 2010 18:25:45 +0000 (UTC) Subject: [Issue 1822] String slicing in 64-bit gdc causes spurious warnings In-Reply-To: References: Message-ID: http://d.puremagic.com/issues/show_bug.cgi?id=1822 Iain Buclaw changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Iain Buclaw 2010-09-01 11:25:29 PDT --- Fixed in hg commit 232 / release 0.25. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- From d-bugmail at puremagic.com Sun Sep 12 14:33:27 2010 From: d-bugmail at puremagic.com (d-bugmail at puremagic.com) Date: Sun, 12 Sep 2010 21:33:27 +0000 (UTC) Subject: [Issue 833] stdint.h not available with solaris In-Reply-To: References: Message-ID: http://d.puremagic.com/issues/show_bug.cgi?id=833 Iain Buclaw changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #1 from Iain Buclaw 2010-09-12 14:32:59 PDT --- stdint.h is there and available in Solaris 10. Won't fix, sorry. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- From d-bugmail at puremagic.com Sun Sep 12 14:37:49 2010 From: d-bugmail at puremagic.com (d-bugmail at puremagic.com) Date: Sun, 12 Sep 2010 21:37:49 +0000 (UTC) Subject: [Issue 834] SegV in gdc during actest.d on Solaris In-Reply-To: References: Message-ID: http://d.puremagic.com/issues/show_bug.cgi?id=834 --- Comment #1 from Iain Buclaw 2010-09-12 14:37:22 PDT --- GCC-3.3 is no longer supported, sorry. If you could test GCC-3.4 (or later) on Solaris 10, would value any feedback/issues/bugs there. The most I know is Solaris isn't supported by the GC (yet), should be trivial to add it though. Regards -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- From jordi at rovira.cat Sun Sep 19 04:01:25 2010 From: jordi at rovira.cat (Jordi) Date: Sun, 19 Sep 2010 20:01:25 +0900 Subject: D2 Blockers? In-Reply-To: References: <4C6A1469.7000106@puremagic.com> Message-ID: 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 >> 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. From ibuclaw at ubuntu.com Mon Sep 20 04:48:42 2010 From: ibuclaw at ubuntu.com (Iain Buclaw) Date: Mon, 20 Sep 2010 11:48:42 +0000 (UTC) Subject: D2 Blockers? References: <4C6A1469.7000106@puremagic.com> Message-ID: == 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. ;-) From jordi at rovira.cat Tue Sep 21 03:49:28 2010 From: jordi at rovira.cat (Jordi) Date: Tue, 21 Sep 2010 19:49:28 +0900 Subject: D2 Blockers? In-Reply-To: References: <4C6A1469.7000106@puremagic.com> Message-ID: 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. From ibuclaw at ubuntu.com Tue Sep 21 10:44:04 2010 From: ibuclaw at ubuntu.com (Iain Buclaw) Date: Tue, 21 Sep 2010 17:44:04 +0000 (UTC) Subject: D2 Blockers? References: <4C6A1469.7000106@puremagic.com> Message-ID: == 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 From ibuclaw at ubuntu.com Tue Sep 28 02:44:56 2010 From: ibuclaw at ubuntu.com (Iain Buclaw) Date: Tue, 28 Sep 2010 09:44:56 +0000 (UTC) Subject: D2 Blockers? References: <4C6A1469.7000106@puremagic.com> Message-ID: I've pushed the initial merge for 2.021 Download available here: http://bitbucket.org/goshawk/gdc/get/ed6460a378bc.gz There are still some features missing, most of which I've mentioned in on this issue: http://bitbucket.org/goshawk/gdc/issue/67/dmd-2021-merge Any input is welcome. Thanks! From fithis2001 at gmail.com Thu Sep 30 07:15:02 2010 From: fithis2001 at gmail.com (Vasilakis) Date: Thu, 30 Sep 2010 17:15:02 +0300 Subject: Automated builds Message-ID: <4CA49B66.2070101@gmail.com> Hi all in this thread, I ran across the project last night and I have started investigating. One question is if it is possible to cooperate with mingw-w64 to provide automated builds for gcc 4.4.* (only d-lang, not other languages) for windows 32bit because they have a very productive build-bot :-) I want to try to build it on msys with latest gcc 4.4.4 tomorrow. One more question. Is gcc 4.5.* support planned or any plans to make it a plugin? Thank you very much for your efforts anyway.