Given that gcc v9 should have built-in support for compiling D code, and that dmd requires gcc, will dmd continue to be supported? Or perhaps have its guts incorporated completely into gcc?

On Friday, 30 November 2018 at 00:43:59 UTC, Andrew Pennebaker wrote:
> Given that gcc v9 should have built-in support for compiling D code, and that dmd requires gcc, will dmd continue to be supported?

dmd will continue to be supported.

On Friday, 30 November 2018 at 00:43:59 UTC, Andrew Pennebaker wrote:
> Given that gcc v9 should have built-in support for compiling D code, and that dmd requires gcc, will dmd continue to be supported? Or perhaps have its guts incorporated completely into gcc?

DMD doesn't really require GCC, GCC is in theory used for compatibility with modules compiled with gcc according to dmd(1), and in practice used for linking.

The linking step could be done with ld alone if you know what to type, and it's honestly pretty complicated, and you still need components from gcc, for various reasons:

LIBGCCDIR=$(cc -print-file-name=)
CRTDIR=/usr/lib/$(cc -dumpmachine)

ld -L $LIBGCCDIR $CRTDIR/Scrt1.o $CRTDIR/crti.o $LIBGCCDIR/crtbeginS.o \
YOUROBJECT.o -E --push-state -static -lphobos2 --pop-state \
-lpthread -lm -lrt -ldl -lc -lgcc -lgcc_s $LIBGCCDIR/crtendS.o $CRTDIR/crtn.o

On Friday, 30 November 2018 at 01:31:12 UTC, mawk wrote:
> On Friday, 30 November 2018 at 00:43:59 UTC, Andrew Pennebaker wrote:
>> Given that gcc v9 should have built-in support for compiling D code, and that dmd requires gcc, will dmd continue to be supported? Or perhaps have its guts incorporated completely into gcc?
>
> DMD doesn't really require GCC, GCC is in theory used for compatibility with modules compiled with gcc according to dmd(1), and in practice used for linking.
>
> The linking step could be done with ld alone if you know what to type, and it's honestly pretty complicated, and you still need components from gcc, for various reasons:
>
> LIBGCCDIR=$(cc -print-file-name=)
> CRTDIR=/usr/lib/$(cc -dumpmachine)
>
> ld -L $LIBGCCDIR $CRTDIR/Scrt1.o $CRTDIR/crti.o $LIBGCCDIR/crtbeginS.o \
> YOUROBJECT.o -E --push-state -static -lphobos2 --pop-state \
> -lpthread -lm -lrt -ldl -lc -lgcc -lgcc_s $LIBGCCDIR/crtendS.o $CRTDIR/crtn.o

gcc is currently required for dmd on FreeBSD, as dmd links to libstdc++.

On Friday, 30 November 2018 at 04:47:26 UTC, Andrew Pennebaker wrote:
>
> gcc is currently required for dmd on FreeBSD, as dmd links to libstdc++.

Parts of dmd are still written in C++ but most of it was converted recently. More on that here:
"DMD backend now in D"
https://forum.dlang.org/thread/psaekt$tah$1@digitalmars.com

On Friday, November 30, 2018 2:43:41 AM MST welkam via Digitalmars-d-learn wrote:
> On Friday, 30 November 2018 at 04:47:26 UTC, Andrew Pennebaker
>
> wrote:
> > gcc is currently required for dmd on FreeBSD, as dmd links to libstdc++.
>
> Parts of dmd are still written in C++ but most of it was
> converted recently. More on that here:
> "DMD backend now in D"
> https://forum.dlang.org/thread/psaekt$tah$1@digitalmars.com

That and the C/C++ compiler could be clang rather than gcc. Even without the backend being ported to D, there shouldn't be an actual dependency on gcc specifically (especially on FreeBSD where you may not even have gcc installed). But if I understand correctly, dmd has always used the C compiler to link on *nix systems rather than using the linker directly. I don't know why it does, but linking via the C compiler is a completely different issue from integrating with it.

Regardless, as to the OP's question about gcc integration, that really doesn't have much to do with dmd. That's a big step forward for gdc, but dmd is the reference compiler. It's where everything is implemented. gdc and ldc are then alternate compilers that use the same front-end. but they're separate projects, and there's really no benefit to us at this point to removing dmd in favor of either of the other two. With dmd, we're in full control of the code and the release cycle, which is not true with llvm or gcc. Honestly, as great as it is for gdc to end up in the official gcc release, in practice, I expect that it's going to be a recipe for a portion of the community using an outdated version of the language (especially when coupled with stuff like LTS releases for Linux distros). That's already been a problem with gdc even without it being in the official gcc release due to how long it's taken them to catch up after the front-end was converted to D.

Also, dmd's backend is the backend that Walter wrote and has used for decades - and it's part of dmc, which he still sells. So, I don't think that he's going to be in hurry to drop it. And if he were, I honestly expect that ldc would have become the reference compiler a while ago, not gdc. But dmd continues to be the reference compiler, and while improving its backend is not the focus, Walter still does work on it (and part of the reason that he's converted it to D is so that he can more easily improve it). Historically, Walter has wanted to stay away from gcc and clang code (or the code of any other compiler that isn't his), because in the past, he's found that being able to say that he's never read the source code has been a good defense against any kind of accusation of code stealing (which definitely matters when he's selling a C++ compiler). So, all the signs are that we're going to continue to have the choice of dmd, ldc, and gdc, and none of them are going anywhere.

- Jonathan M Davis