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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019