From: Eric Gallager <egall@gwmail.gwu.edu>
To: Jeff Law <jeffreyalaw@gmail.com>
Cc: Iain Buclaw <ibuclaw@gdcproject.org>,
gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] configure, d: Add support for bootstrapping the D front-end
Date: Fri, 29 Oct 2021 17:37:44 -0400 [thread overview]
Message-ID: <CAMfHzOvpGHL6LvKrk23wv+_VTjbXS7uj6p_BApG9oTrU3kgW7Q@mail.gmail.com> (raw)
In-Reply-To: <2fcd01b2-5a2b-3b2f-488b-09f0bf9d0fc9@gmail.com>
On Thu, Oct 28, 2021 at 2:38 PM Jeff Law via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
>
>
> On 10/9/2021 7:32 AM, Iain Buclaw via Gcc-patches wrote:
> > Hi,
> >
> > The implementation of the D front-end in GCC is based on the original
> > C++ version of the D programming language compiler, which was ported to
> > D itself in version 2.069.0 (released in 2015). To keep it somewhat
> > up-to-date, I have been backporting fixes from upstream back into C++,
> > but this stopped at version 2.076.1 (released in 2017), and since then
> > I've only been keeping the front-end only updated enough to still be
> > able to build the latest version of the D language (now 2.098.0).
> >
> > Reasons for putting off switching to the D implementation immediately
> > after GCC 9 has been a mixture of the front-end not being ready to use,
> > and current portability status of the D core runtime library.
> >
> > It has come to the point now that I'm happy enough with the process to
> > switch out the C++ sources in gcc/d/dmd with D sources.
> >
> > Before that, there's only this patch that makes the required changes to
> > GCC itself in order to have a D front-end written in D itself.
> >
> > The rest of the series only changes code in the D language front-end or
> > libphobos standard library, so I've left that out for the time being
> > until I'm ready to commit it.
> >
> > The complete set of changes are in the ibuclaw/gdc branch under
> > users/ibuclaw. It has been well-tested on x86_64-linux-gnu for about 3
> > years now, and I've also been testing the self-hosted compiler on
> > powerpc64le-linux-gnu as well with no regressions from the D language
> > testsuite run.
> >
> > Does anything stand out as being problematic in this patch, or may need
> > splitting out first? Or would it be OK for trunk?
> >
> > Thanks,
> > Iain.
> >
> > ---
> > ChangeLog:
> >
> > * Makefile.def: Add bootstrap to libbacktrace, libphobos, zlib, and
> > libatomic.
> > * Makefile.in: Regenerate.
> > * Makefile.tpl (POSTSTAGE1_HOST_EXPORTS): Fix command for GDC.
> > (STAGE1_CONFIGURE_FLAGS): Add --with-libphobos-druntime-only if
> > target-libphobos-bootstrap.
> > (STAGE2_CONFIGURE_FLAGS): Likewise.
> > * configure: Regenerate.
> > * configure.ac: Add support for bootstrapping D front-end.
> >
> > config/ChangeLog:
> >
> > * acx.m4 (ACX_PROG_GDC): New m4 function.
> >
> > gcc/ChangeLog:
> >
> > * Makefile.in (GDC): New variable.
> > (GDCFLAGS): New variable.
> > * configure: Regenerate.
> > * configure.ac: Add call to ACX_PROG_GDC. Substitute GDCFLAGS.
> >
> > gcc/po/ChangeLog:
> >
> > * EXCLUDES: Remove d/dmd sources from list.
> Presumably this means that the only way to build D for the first time on
> a new target is to cross from an existing target that supports D, right?
>
> I think that's not unreasonable and I don't think we want to increase
> the burden of maintaining an old codebase just for the sake of a
> marginally easier bootstrap process for a new target.
>
> So I think you should go with this whenever you're ready.
>
> jeff
>
There should be some sort of note about this in the documentation,
IMO; both install.texi and the "Caveats" section of
gcc-12/changes.html (and possibly other places).
Eric
next prev parent reply other threads:[~2021-10-29 21:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-09 13:32 Iain Buclaw
2021-10-13 16:17 ` [PATCH, ping] " ibuclaw
2021-10-25 8:09 ` Ping: [PATCH v2] " Iain Buclaw
2021-10-28 18:37 ` [PATCH] " Jeff Law
2021-10-29 21:37 ` Eric Gallager [this message]
2021-12-01 13:57 ` Thomas Schwinge
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMfHzOvpGHL6LvKrk23wv+_VTjbXS7uj6p_BApG9oTrU3kgW7Q@mail.gmail.com \
--to=egall@gwmail.gwu.edu \
--cc=gcc-patches@gcc.gnu.org \
--cc=ibuclaw@gdcproject.org \
--cc=jeffreyalaw@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).