public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Thomas Schwinge <thomas@codesourcery.com>
To: Iain Buclaw <ibuclaw@gdcproject.org>
Cc: <gcc-patches@gcc.gnu.org>, Eric Gallager <egall@gwmail.gwu.edu>,
	"Jeff Law" <jeffreyalaw@gmail.com>
Subject: Re: [PATCH] configure, d: Add support for bootstrapping the D front-end
Date: Wed, 1 Dec 2021 14:57:57 +0100	[thread overview]
Message-ID: <87mtlk8m1m.fsf@euler.schwinge.homeip.net> (raw)
In-Reply-To: <CAMfHzOvpGHL6LvKrk23wv+_VTjbXS7uj6p_BApG9oTrU3kgW7Q@mail.gmail.com>

Hi!

On 2021-10-29T17:37:44-0400, Eric Gallager via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
> 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:
>> > 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).  [...]
>> > 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.

Congratulations: self-hosting compiler!

That, of course, makes the GCC/D compilation process more difficult:

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

(Some may argue "burden" vs. "marginally", but yes, I agree.)  Plus, the
problem that also for non-cross (native) builds, you now have a baseline
GCC/D compiler requirement:

> There should be some sort of note about this in the documentation,
> IMO; both install.texi

That has been done.

    +In order to build GDC, the D compiler, you need a working GDC
    +compiler (GCC version 9.1 or later), as the D front end is written in D.

> and the "Caveats" section of
> gcc-12/changes.html (and possibly other places).

That not yet, but yes, I agree that should be done, too.


So it's now a requirement to build/bootstrap GCC/D with GCC 9.1 (or
newer, of course) -- which is quite different from the current GCC 4.8
requirement for all other GCC parts (including self-hosted GCC/Ada, by
the way, which also is happy with GCC 4.8).

I'm one of those (few, I guess?) doing bootstrap verification builds with
actual old GCC 4.8 ("gcc-4.8 (Ubuntu 4.8.4-2ubuntu1~14.04.4) 4.8.4",
precisely), and that now obviously doesn't cover GCC/D anymore, for
example with '--enable-languages=all' (and without the GDC 4.8 packages
installed):

    [...]
    +checking for gdc... no
    [...]
    +configure: WARNING: GDC is required to build d
     configure: WARNING: --enable-host-shared required to build jit
    -The following languages will be built: c,ada,c++,d,fortran,go,lto,objc,obj-c++
    +The following languages will be built: c,ada,c++,fortran,go,lto,objc,obj-c++
     *** This configuration is not supported in the following subdirectories:
    -     target-liboffloadmic
    +     target-libphobos target-zlib target-liboffloadmic
         (Any other directories should still work fine.)
    [...]

..., or error for explicit '--enable-languages=d'.

So I built myself a stock GCC 9.1 with '--enable-languages=d', and via
'[...]/configure [...] CC=gcc-4.8 CXX=g++-4.8 GDC=[GCC 9.1]/bin/gdc [...]'
I'm able to successfully bootstrap GCC, including GCC/D, in a mixed
GCC 4.8/9.1 configuration, with subsequent good-looking 'make check-d'
results.  Per my superficial review of the build log file, the
'[GCC 9.1]/bin/gdc' indeed is only used during stage 1 build, as it
should be.  So that's good enough as far as I'm concerned, and unless
anyone sees any reason why such a mixed GCC 4.8/9.1 configuration would
be bad, may it be worth putting such information (may 'configure' with
'GDC=[GCC 9.1]/bin/gdc') into the documentation, too?


Grüße
 Thomas
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

      reply	other threads:[~2021-12-01 13:58 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
2021-12-01 13:57     ` Thomas Schwinge [this message]

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=87mtlk8m1m.fsf@euler.schwinge.homeip.net \
    --to=thomas@codesourcery.com \
    --cc=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).