www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Which D compiler is the most maintained and future-proof? [DMD GDC and

reply BoQsc <vaidas.boqsc gmail.com> writes:
There are three compilers present in the Dlang website: DMD GDC 
and LDC
Jul 24 2023
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
There isn't a huge concern with which one you use.

Its quite common to use dmd for development, and ldc for release for 
example.

They all share the same frontend, so they really only differ between 
them by their glue code to the relevant backend and some modules in 
druntime that are optional. Oh and inline assembly, although there is 
some compat code in ldc/gdc for dmd style.

If dmd dies, so does ldc/gdc basically. Each one sees active development 
although gdc only has one developer. Ldc keeps up with the dmd releases 
pretty well.
Jul 24 2023
next sibling parent reply devosalain <devosalain ymail.com> writes:
I could be interesting to also compare the licenses of the 3 
compilers.
Jul 24 2023
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 25/07/2023 1:26 AM, devosalain wrote:

 I could be interesting to also compare the licenses of the 3 compilers.


There isn't a huge difference between them.

The frontend, druntime and most of phobos (minus zlib and curl) are all 
Boost regardless of compiler.

That just leaves backends, which depends upon GCC and LLVM. So if you 
can use GCC and Clang, your fine to use GDC and LDC.
Jul 24 2023
parent Ernesto Castellotti <erny.castell gmail.com> writes:
On Monday, 24 July 2023 at 13:51:18 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

 On 25/07/2023 1:26 AM, devosalain wrote:

 I could be interesting to also compare the licenses of the 3 
 compilers.


 There isn't a huge difference between them.

 The frontend, druntime and most of phobos (minus zlib and curl) 
 are all Boost regardless of compiler.

 That just leaves backends, which depends upon GCC and LLVM. So 
 if you can use GCC and Clang, your fine to use GDC and LDC.


As far as I know any contribution to GCC has to be done under a 
GPLv3 compatible license (like Boost) and then it's all 
redistributed under GPLv3+Runtime Exception clause despite having 
other licenses previously.
So GDC since it went mainline GCC should be distributed under 
GPLv3.
Jul 25 2023
prev sibling parent reply cc <cc nevernet.com> writes:
On Monday, 24 July 2023 at 09:29:09 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

 There isn't a huge concern with which one you use.

 Its quite common to use dmd for development, and ldc for 
 release for example.

 They all share the same frontend, so they really only differ 
 between them by their glue code to the relevant backend and 
 some modules in druntime that are optional. Oh and inline 
 assembly, although there is some compat code in ldc/gdc for dmd 
 style.

 If dmd dies, so does ldc/gdc basically. Each one sees active 
 development although gdc only has one developer. Ldc keeps up 
 with the dmd releases pretty well.


Is there any list of known significant "gotchas" with moving to 
LDC from DMD?  Any unexpected surprises to watch out for or be 
careful for?  I'm thinking of all the "features" of DMD that are 
now considered verboten by many users (e.g. compiling with 
-release, disabling of asserts or array bounds checking, etc).  
Known edge cases of compiler optimization causing different 
behavior between vendors?
Jul 24 2023
next sibling parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 25/07/2023 1:30 AM, cc wrote:

 Is there any list of known significant "gotchas" with moving to LDC from 
 DMD?  Any unexpected surprises to watch out for or be careful for?  I'm 
 thinking of all the "features" of DMD that are now considered verboten 
 by many users (e.g. compiling with -release, disabling of asserts or 
 array bounds checking, etc). Known edge cases of compiler optimization 
 causing different behavior between vendors?


No, there is no list.

The main gotcha I know of is inline assembly being a bit different. Also 
the glue code for LDC hasn't got ``extern(Objective-C)`` implemented 
currently. I don't know about GDC.

Over all, if you are familiar with GCC & Clang, you'll be ok. A lot of 
the flags from dmd have a comparable version (if not split up further) 
in LDC and GDC.
Jul 24 2023
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 7/24/23 9:30 AM, cc wrote:

 On Monday, 24 July 2023 at 09:29:09 UTC, Richard (Rikki) Andrew 
 Cattermole wrote:

 There isn't a huge concern with which one you use.

 Its quite common to use dmd for development, and ldc for release for 
 example.

 They all share the same frontend, so they really only differ between 
 them by their glue code to the relevant backend and some modules in 
 druntime that are optional. Oh and inline assembly, although there is 
 some compat code in ldc/gdc for dmd style.

 If dmd dies, so does ldc/gdc basically. Each one sees active 
 development although gdc only has one developer. Ldc keeps up with the 
 dmd releases pretty well.




If DMD dies, the other two will live on. This is open source after all.


 
 Is there any list of known significant "gotchas" with moving to LDC from 
 DMD?  Any unexpected surprises to watch out for or be careful for?  I'm 
 thinking of all the "features" of DMD that are now considered verboten 
 by many users (e.g. compiling with -release, disabling of asserts or 
 array bounds checking, etc). Known edge cases of compiler optimization 
 causing different behavior between vendors?
 


DMD is the point of all D feature introductions, and so anything that 
works with LDC should work with DMD.

It's the other way around that might cause trouble, since there may be 
DMD features which haven't yet made it into LDC.

There are also subtle ways to consider things "broken" which might 
affect you if you care about that. Like for instance floating point 
handling is different, so you might not get exactly the same binary results.

-Steve
Jul 24 2023
parent Johan <j j.nl> writes:
On Monday, 24 July 2023 at 13:51:06 UTC, Steven Schveighoffer 
wrote:

 DMD is the point of all D feature introductions, and so 
 anything that works with LDC should work with DMD.

 It's the other way around that might cause trouble, since there 
 may be DMD features which haven't yet made it into LDC.


I understand what you mean, but a key reason to use LDC or GDC is 
for all the features that DMD does not have.
- support for more platforms
- CPU intrinsics, more extensive inline assembly
- sanitizers, fuzzing
- special function/variable attributes (e.g.  section,  weak, ...)

To the OP's question, I don't think _any_ of the 3 compilers is 
"future proof". But we'd need a better definition of what OP 
means with "future proof" to give a better answer.

regards,
   Johan
Jul 24 2023
prev sibling next sibling parent Dennis <dkorpel gmail.com> writes:
On Monday, 24 July 2023 at 13:30:27 UTC, cc wrote:

 Is there any list of known significant "gotchas" with moving to 
 LDC from DMD?  Any unexpected surprises to watch out for or be 
 careful for?


- DMD has weak linking for all functions by default (mostly as a 
workaround to several bugs). In LDC, you might get 'duplicate 
definition' errors when linking D objects that succeeds when 
compiled with dmd.

- DMD supports C opaque struct definitions in headers (though 
arguably a bug as well) while LDC will complain, see 
https://github.com/ldc-developers/ldc/issues/3817


 Known edge cases of compiler optimization causing different 
 behavior between vendors?


LDC can optimize much more aggressively, so if your code has 
undefined behavior, it's more likely to manifest as a bug with 
LDC. I had a unittest that succeeded with dmd but failed with 
`ldc2 -O3` because there was a bitshift larger than 63. DMD 
didn't care much (it would just do modulo 64), but LDC optimized 
the function based on the assumption that a parameter could never 
be 0, which I didn't intend.
Jul 24 2023
prev sibling parent IchorDev <zxinsworld gmail.com> writes:
On Monday, 24 July 2023 at 13:30:27 UTC, cc wrote:

 Is there any list of known significant "gotchas" with moving to 
 LDC from DMD?  Any unexpected surprises to watch out for or be 
 careful for?  I'm thinking of all the "features" of DMD that 
 are now considered verboten by many users (e.g. compiling with 
 -release, disabling of asserts or array bounds checking, etc).  
 Known edge cases of compiler optimization causing different 
 behavior between vendors?


Some LDC stuff: 
https://wiki.dlang.org/LDC-specific_language_changes#Violations_of_the_specification
Pretty much everything for GDC: 
https://gcc.gnu.org/onlinedocs/gdc/Missing-Features.html
Jul 24 2023
prev sibling parent Guillaume Piolat <first.name gmail.com> writes:
On Monday, 24 July 2023 at 09:20:05 UTC, BoQsc wrote:

 There are three compilers present in the Dlang website: DMD GDC 
 and LDC


DMD can build much faster than LDC. In some cases it is quite 
extreme, for example the product I work on has a 3.6x faster 
debug build time with DMD (well, only with --combined -b debug).

It may be a bit more crucial that it seems to work with DMD for 
fast iteration, if you need a lot of experiments. It seems the 
product is benefiting from using DMD for prototyping, even though 
it was an accident at first.

I wanted to compare the run times, but the same project doesn't 
build with DMD and optimizations. Usually LDC is 2x the speed, 
and LLVM output accelerate a bit over time as the optimizer gets 
smarter.

(Numbers with LDC 1.33.0 and DMD 2.104.0)
Jul 24 2023