www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - GCC with D have been finally been released.

reply 12345swordy <alexanderheistermann gmail.com> writes:
https://gcc.gnu.org/gcc-9/changes.html
May 03
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, May 03, 2019 at 03:37:23PM +0000, 12345swordy via Digitalmars-d wrote:
 https://gcc.gnu.org/gcc-9/changes.html
WOOHOO!!! Celebration! But... 2.076... is ancient. :-/ That's like *8* releases behind dmd/ldc. I wish gdc were more up-to-date. But I understand that Iain is constrained by the GCC release schedule. T -- That's not a bug; that's a feature!
May 03
parent reply Johannes Pfau <nospam example.com> writes:
Am Fri, 03 May 2019 10:03:47 -0700 schrieb H. S. Teoh:

 On Fri, May 03, 2019 at 03:37:23PM +0000, 12345swordy via Digitalmars-d
 wrote:
 https://gcc.gnu.org/gcc-9/changes.html
WOOHOO!!! Celebration! But... 2.076... is ancient. :-/ That's like *8* releases behind dmd/ldc. I wish gdc were more up-to-date. But I understand that Iain is constrained by the GCC release schedule. T
Well, you should use gcc trunk then ;-) belka just wrote this in the GDC slack channel:
 GDC with D v2.086.0-rc.1 passes the original testsuite now (from 2.083).
We'll merge this to gcc trunk shortly after the 2.086 test suite passes and GCC 10 stage 1 development opens (or has it already opened? I'm not sure). There's only one reason GCC 9 ships 2.076: We need one GCC/GDC release which builds without any D compiler, i.e. which still uses the C++ frontend. There's no newer C++ frontend available, so 2.076 (+ many backports, see dmd-cxx branches in the dlang dmd/druntime/phobos branches) was the latest version we could ship. -- Johannes
May 03
next sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On Fri, 3 May 2019 at 19:15, Johannes Pfau via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 Am Fri, 03 May 2019 10:03:47 -0700 schrieb H. S. Teoh:

 On Fri, May 03, 2019 at 03:37:23PM +0000, 12345swordy via Digitalmars-d
 wrote:
 https://gcc.gnu.org/gcc-9/changes.html
WOOHOO!!! Celebration! But... 2.076... is ancient. :-/ That's like *8* releases behind dmd/ldc. I wish gdc were more up-to-date. But I understand that Iain is constrained by the GCC release schedule. T
Well, you should use gcc trunk then ;-) belka just wrote this in the GDC slack channel:
 GDC with D v2.086.0-rc.1 passes the original testsuite now (from 2.083).
We'll merge this to gcc trunk shortly after the 2.086 test suite passes and GCC 10 stage 1 development opens (or has it already opened? I'm not sure).
GCC 10 stage 1 is open. Time to destroy trunk! -- Iain
May 03
parent reply Walter Bright <newshound2 digitalmars.com> writes:
I can't thank Iain and Johannes enough! It's a critical achievement for D's 
future. It will open a lot of doors for us.
May 03
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, May 03, 2019 at 01:16:05PM -0700, Walter Bright via Digitalmars-d wrote:
 I can't thank Iain and Johannes enough! It's a critical achievement
 for D's future. It will open a lot of doors for us.
Indeed. Most (all?) Linux distros use GCC as the default toolchain for their repository packages. Having D available means we can now ship D software to these distros without fearing that there's no compiler available, or that users will have to download an external compiler, which comes with a host of issues like compatibility with system libraries, proper integration, etc.. It also means prospective users can just install gdc from their official distro repo and start playing around with D. (This has been true for some distros for a while now, but having it as an official part of GCC means we don't have to do the porting work manually anymore -- distros will virtually do it for us.) Of course, most of this applies to non-Linux environments that happen to use GCC too. (Though I surmise that would be a much smaller audience.) T -- It is impossible to make anything foolproof because fools are so ingenious. -- Sammy
May 03
prev sibling next sibling parent Nemanja Boric <dlang nemanjaboric.com> writes:
On Friday, 3 May 2019 at 20:16:05 UTC, Walter Bright wrote:
 I can't thank Iain and Johannes enough! It's a critical 
 achievement for D's future. It will open a lot of doors for us.
Congratulations to Iain and Johannes and the entire GDC team!
May 03
prev sibling parent Yatheendra <kht9 jeemail.com> writes:
On Friday, 3 May 2019 at 20:16:05 UTC, Walter Bright wrote:
 I can't thank Iain and Johannes enough! It's a critical 
 achievement for D's future. It will open a lot of doors for us.
This is major news for me, a lurker in these parts. Kudos to Iain and Johannes for achieving this (and to Walter for decoupling the frontend in the first place). Does GTK's Vala need to exist now!
May 11
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, May 03, 2019 at 05:12:07PM +0000, Johannes Pfau via Digitalmars-d wrote:
 Am Fri, 03 May 2019 10:03:47 -0700 schrieb H. S. Teoh:
[...]
 But... 2.076... is ancient. :-/  That's like *8* releases behind
 dmd/ldc.  I wish gdc were more up-to-date.  But I understand that
 Iain is constrained by the GCC release schedule.
[...]
 Well, you should use gcc trunk then ;-)
I suppose I could, yes. But I balk at the prospect of building gcc myself. Unlike the ease of building dmd, building gcc is something that makes me tremble with fear lest the delicate build infrastructure collapses upon me. I'm not (yet) desperate enough to do it, in spite of having done it before.
 belka just wrote this in the GDC slack channel:
 GDC with D v2.086.0-rc.1 passes the original testsuite now (from
 2.083).
We'll merge this to gcc trunk shortly after the 2.086 test suite passes and GCC 10 stage 1 development opens (or has it already opened? I'm not sure).
Wonderful news!
 There's only one reason GCC 9 ships 2.076: We need one GCC/GDC release
 which builds without any D compiler, i.e. which still uses the C++
 frontend. There's no newer C++ frontend available, so 2.076 (+ many
 backports, see dmd-cxx branches in the dlang dmd/druntime/phobos
 branches) was the latest version we could ship.
[...] Ahhh, so *that's* the reason. Makes sense. We need GCC 9 with a C++ frontend so that we can bootstrap a self-hosting D compiler in later releases. Understood. Thanks for the clarification! T -- IBM = I'll Buy Microsoft!
May 03
parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Friday, 3 May 2019 at 17:48:16 UTC, H. S. Teoh wrote:
 belka just wrote this in the GDC slack channel:
 GDC with D v2.086.0-rc.1 passes the original testsuite now 
 (from
 2.083).
We'll merge this to gcc trunk shortly after the 2.086 test suite passes and GCC 10 stage 1 development opens (or has it already opened? I'm not sure).
Wonderful news!
Agreed.
May 05
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, May 03, 2019 at 07:26:35PM +0200, Iain Buclaw via Digitalmars-d wrote:
 On Fri, 3 May 2019 at 19:15, Johannes Pfau via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
[...]
 belka just wrote this in the GDC slack channel:
 GDC with D v2.086.0-rc.1 passes the original testsuite now (from
 2.083).
We'll merge this to gcc trunk shortly after the 2.086 test suite passes and GCC 10 stage 1 development opens (or has it already opened? I'm not sure).
GCC 10 stage 1 is open. Time to destroy trunk!
[...] Does this mean from GCC 10 onwards, GCC releases will closely track DMD releases, the same way LDC does? *That* would be very, very nice indeed. And now that GCC officially supports D, new opportunities arise. E.g., we could ship D programs in Linux distros now, and nobody will be able to complain about needing an obscure compiler to build said programs. Hearty thanks to Iain for pushing this through to completion! T -- Unix was not designed to stop people from doing stupid things, because that would also stop them from doing clever things. -- Doug Gwyn
May 03
next sibling parent Eugene Wissner <belka caraus.de> writes:
On Friday, 3 May 2019 at 17:52:22 UTC, H. S. Teoh wrote:
 Does this mean from GCC 10 onwards, GCC releases will closely 
 track DMD releases, the same way LDC does?  *That* would be 
 very, very nice indeed.
We have now only one frontend to maintain, so yes it should be possible. GCC doesn't release as often as DMD, but I personally don't see much value in porting every DMD version, it just shouldn't be outdated. There are sometimes interesting releases like 2.086 and some releases bring only new regressions. I'm currently using GDC 2.081.2 and I can't say I'm missing something from the newer versions.
May 03
prev sibling parent wjoe <none example.com> writes:
 GCC with D have been finally been released.
yes. YES. YEEEEEEEEEESSSSSSSSSS!!!! thank you so much :D On Friday, 3 May 2019 at 17:52:22 UTC, H. S. Teoh wrote:
 On Fri, May 03, 2019 at 07:26:35PM +0200, Iain Buclaw via 
 Digitalmars-d wrote:
 On Fri, 3 May 2019 at 19:15, Johannes Pfau via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:
[...]
 belka just wrote this in the GDC slack channel:
 GDC with D v2.086.0-rc.1 passes the original testsuite now 
 (from
 2.083).
We'll merge this to gcc trunk shortly after the 2.086 test suite passes and GCC 10 stage 1 development opens (or has it already opened? I'm not sure).
GCC 10 stage 1 is open. Time to destroy trunk!
[...] Does this mean from GCC 10 onwards, GCC releases will closely track DMD releases, the same way LDC does? *That* would be very, very nice indeed.
The requirement, as far as I understand, is: the last/previous version must be able to build the new one. Hence it shouldn't be a problem to use the latest DMD release from now on. However, according to the release cycle [1] I'd expect something like yearly DMD version granularity. (yearly granularity - how to express that in English?) [1] https://www.gnu.org/software/gcc/develop.html#timeline
May 03
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/3/19 11:37 AM, 12345swordy wrote:
 https://gcc.gnu.org/gcc-9/changes.html
Congratulations Iain for a monumental achievement!
May 03
prev sibling next sibling parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Friday, 3 May 2019 at 15:37:23 UTC, 12345swordy wrote:
 https://gcc.gnu.org/gcc-9/changes.html
👏
May 03
prev sibling next sibling parent Stefanos Baziotis <sdi1600105 di.uoa.gr> writes:
On Friday, 3 May 2019 at 15:37:23 UTC, 12345swordy wrote:
 https://gcc.gnu.org/gcc-9/changes.html
Amazing, congratulations to the whole GDC team! - Stefanos
May 03
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Friday, 3 May 2019 at 15:37:23 UTC, 12345swordy wrote:
 https://gcc.gnu.org/gcc-9/changes.html
Huge congratulations to Iain, Johannes, and team :-) I have to add a particular note of personal thanks here: it was Iain picking up the reins of GDC, and getting it to the point where a reasonably up to date D2 GDC made it into Ubuntu 12.04, that unlocked really getting to grips with the language for me. And that unlocked a host of wonderful professional and personal opportunities (including the one that gave me the pleasure of having Iain as a work colleague). So I think we should recognize Iain, not just for the wonderful work he has done, but for the extent to which he has empowered other people to use D and do wonderful things with it. It's one of the most important contributions that anyone can make. So thank you Iain and team, and here's looking forward to all the other wonderful stuff you are making possible with this latest achievement :-)
May 05
prev sibling parent reply Ron Tarrant <rontarrant gmail.com> writes:
On Friday, 3 May 2019 at 15:37:23 UTC, 12345swordy wrote:
 https://gcc.gnu.org/gcc-9/changes.html
That's pretty cool! I have a question about binary compatibility between compilers. I read somewhere that LDC and DMD aren't binary compatible, so... Will GDC be binary compatible with one or more of the already-existing D compilers? Secondly, does it matter? (I'm still not clear on that.)
May 05
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, May 05, 2019 at 07:34:18PM +0000, Ron Tarrant via Digitalmars-d wrote:
 On Friday, 3 May 2019 at 15:37:23 UTC, 12345swordy wrote:
 https://gcc.gnu.org/gcc-9/changes.html
That's pretty cool! I have a question about binary compatibility between compilers. I read somewhere that LDC and DMD aren't binary compatible, so... Will GDC be binary compatible with one or more of the already-existing D compilers?
I just tested LDC and GDC, and they aren't compatible either. Probably because they each ship with their own version of Phobos, and link with their own C runtimes that aren't compatible with each other.
 Secondly, does it matter? (I'm still not clear on that.)
I think it's generally accepted that you have to use the same compiler to compile an entire program. I've never heard of it being considered a bug that the output of two different compilers are incompatible. It'd be great if it could somehow still work anyway, but generally I don't think it's expected to. And I would think it shouldn't matter which compiler you use as long as your code doesn't depend on compiler-specific features; you could just recompile with a different compiler if need be, and go along your merry way. T -- Music critic: "That's an imitation fugue!"
May 07
next sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Tue, 07 May 2019 11:13:08 -0700 schrieb H. S. Teoh:

 Will GDC be binary compatible with one or more of the already-existing
 D compilers?
I just tested LDC and GDC, and they aren't compatible either. Probably because they each ship with their own version of Phobos, and link with their own C runtimes that aren't compatible with each other.
Unfortunately the compilers are currently not ABI compatible. I think it shouldn't be too difficult to fix this though.
 
 Secondly, does it matter? (I'm still not clear on that.)
I think it's generally accepted that you have to use the same compiler to compile an entire program. I've never heard of it being considered a bug that the output of two different compilers are incompatible. It'd be great if it could somehow still work anyway, but generally I don't think it's expected to.
Are you talking about D specifically or about any language in general? gcc and clang are abi compatible as far as I know and the same should be true for clang and msvc. It is probably not necessary to be compatible on object file level, but at least shared libraries need to be compatible between compilers. Otherwise you will force linux distributions to choose only one compiler, as nobody wants to have 3 packages for every library (one for every compiler). However, I don't think there are many compiler specific runtime hooks, so it should be possible to get e.g. gdc compiled code linking to a ldc compiled druntime. I guess the biggest problem here is exception handling. -- Johannes
May 07
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, May 07, 2019 at 09:13:57PM +0000, Johannes Pfau via Digitalmars-d wrote:
 Am Tue, 07 May 2019 11:13:08 -0700 schrieb H. S. Teoh:
[...]
 I think it's generally accepted that you have to use the same
 compiler to compile an entire program.  I've never heard of it being
 considered a bug that the output of two different compilers are
 incompatible.  It'd be great if it could somehow still work anyway,
 but generally I don't think it's expected to.
Are you talking about D specifically or about any language in general? gcc and clang are abi compatible as far as I know and the same should be true for clang and msvc. It is probably not necessary to be compatible on object file level, but at least shared libraries need to be compatible between compilers. Otherwise you will force linux distributions to choose only one compiler, as nobody wants to have 3 packages for every library (one for every compiler).
That's a very good point. If we stick to platform ABI conventions (and we have to, and do, because that's the only way we could interoperate with C/C++), then in theory libraries should be compatible at the ABI level. But there's a grey area where D features may not have a fixed implementation in the platform ABI, and different compilers may implement such features differently, causing ABI incompatibility. So I retract my statement about compiler incompatibilities. Still, I ran into linker problems with '*-personality-*' symbols, which appear to be caused by different compiler quirks / implementation choices. But I only tested with object files, so perhaps that's not a fair comparison. I'd expect at the .so level gdc and ldc compiled code ought to be able to interoperate.
 However, I don't think there are many compiler specific runtime hooks,
 so it should be possible to get e.g. gdc compiled code linking to a
 ldc compiled druntime. I guess the biggest problem here is exception
 handling.
[...] What is it about exception handling that causes problems? T -- An imaginary friend squared is a real enemy.
May 08
parent Johannes Pfau <nospam example.com> writes:
Am Wed, 08 May 2019 09:46:55 -0700 schrieb H. S. Teoh:
 
 It is probably not necessary to be compatible on object file level, but
 at least shared libraries need to be compatible between compilers.
 Otherwise you will force linux distributions to choose only one
 compiler, as nobody wants to have 3 packages for every library (one for
 every compiler).
That's a very good point. If we stick to platform ABI conventions (and we have to, and do, because that's the only way we could interoperate with C/C++), then in theory libraries should be compatible at the ABI level. But there's a grey area where D features may not have a fixed implementation in the platform ABI, and different compilers may implement such features differently, causing ABI incompatibility.
The personality functions are used by compilers for exception handling, but as the function itself is in druntime you will always have problems to use druntime of compiler X with any other code using exceptions compiled with compiler Y.
 
 So I retract my statement about compiler incompatibilities.  Still, I
 ran into linker problems with '*-personality-*' symbols, which appear to
 be caused by different compiler quirks / implementation choices. But I
 only tested with object files, so perhaps that's not a fair comparison.
 I'd expect at the .so level gdc and ldc compiled code ought to be able
 to interoperate.
 
 
 However, I don't think there are many compiler specific runtime hooks,
 so it should be possible to get e.g. gdc compiled code linking to a ldc
 compiled druntime. I guess the biggest problem here is exception
 handling.
[...] What is it about exception handling that causes problems? T
The (name of the) personality functions ;-) I guess the actual exception handling implementation might also differ a little between compilers. But as all compilers use libgcc's unwind functions on linux, AFAIK, it should be possible to merge the different implementations. -- Johannes
May 08
prev sibling parent reply Ron Tarrant <rontarrant gmail.com> writes:
On Tuesday, 7 May 2019 at 18:13:08 UTC, H. S. Teoh wrote:

 And I would think it shouldn't matter which compiler you use as 
 long as your code doesn't depend on compiler-specific features; 
 you could just recompile with a different compiler if need be, 
 and go along your merry way.
Is this also the case for libraries? A library compiled with (for instance) DMD can't be used from an application compiled with GDC?
May 08
parent Ron Tarrant <rontarrant gmail.com> writes:
On Wednesday, 8 May 2019 at 13:38:23 UTC, Ron Tarrant wrote:
 On Tuesday, 7 May 2019 at 18:13:08 UTC, H. S. Teoh wrote:

 And I would think it shouldn't matter which compiler you use 
 as long as your code doesn't depend on compiler-specific 
 features; you could just recompile with a different compiler 
 if need be, and go along your merry way.
Is this also the case for libraries? A library compiled with (for instance) DMD can't be used from an application compiled with GDC?
On Tuesday, 7 May 2019 at 21:13:57 UTC, Johannes Pfau wrote:
 It is probably not necessary to be compatible on object file 
 level, but at least shared libraries need to be compatible 
 between compilers. Otherwise you will force linux distributions 
 to choose only one compiler, as nobody wants to have 3 packages 
 for every library (one for every compiler).
Well, that'll teach me to read the replies to the post I'm replying to before replying... if that makes any sense.
May 08