Which D compiler is the most maintained and future-proof? [DMD GDC and LDC]

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.

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?

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.

July 24

Re: Which D compiler is the most maintained and future-proof? [DMD GDC and LDC]

Posted by Steven Schveighoffer
in reply to cc

Permalink

Steven Schveighoffer

Posted in reply to cc

Permalink

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

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.

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.

Forums