public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Mateus Carmo Martins de Freitas Barbosa <mateus.carmo.barbosa@usp.br>
To: David Malcolm <dmalcolm@redhat.com>
Cc: gcc@gcc.gnu.org, Philip Herron <redbrain@gcc.gnu.org>
Subject: Re: Rust front-end
Date: Fri, 30 Aug 2019 20:24:00 -0000	[thread overview]
Message-ID: <CACeY_cj5+MAtafALP02Ayzzz71Ojt5K1TX1s9AU-HLfNdJH0sQ@mail.gmail.com> (raw)
In-Reply-To: <1566917881.3379.24.camel@redhat.com>

> One approach would be something like how the GCC Go frontend works,
> which uses a library shared with the other Go compiler implementation
> to parse the code, and turn it into GCC's IR, which then goes through
GCC's optimizer and backend.

I'm not familiar with rustc's internal working. Its code seems to be
pretty modular but I'm not sure whether those modules are available for external
use (i.e. have a stable API).
If they are, I assume that with this approach it would be necessary to transform
rust's MIR into one of GCC's IRs (e.g. GIMPLE or GENERIC), and there doesn't
seem to be any MIR specification yet
(<https://internals.rust-lang.org/t/mir-specification/6111/5>), so it's likely
not stable enough.

> Another approach would be to build a gcc-based backend to the existing
> rust compiler, as an alternative to its LLVM-based backend, rather than
> a rust frontend to gcc.  libgccjit (despite its name) has the ability
> to generate ahead-of-time code (e.g. .o files), and has rust bindings,
> and thus could be embedded inside rustc - in theory, at least.

This approach seems cleaner to me. libgccjit seems to abstract away IR details,
and it's really convenient that Rust bindings already exist.

I'll take this discussion to the rustc project. Thanks to all.

On Tue, Aug 27, 2019 at 11:58 AM David Malcolm <dmalcolm@redhat.com> wrote:
>
> On Fri, 2019-08-23 at 11:10 -0300, Mateus Carmo Martins de Freitas
> Barbosa wrote:
> > I'm interested in working on the Rust front-end for GCC.
> >
> > So far I've cloned the repository <https://github.com/redbrain/gccrs.
> > git>
> > and tried to compile it as described in <https://gcc.gnu.org/wiki/Rus
> > tFrontEnd>.
> > I've compiled it outside of the gcc directory tree with
> >
> > $ ../gccrs/configure --prefix=/opt/gccrs --enable-languages=rust
> > --disable-multilib --disable-bootstrap
> > $ make
> >
> >
> > But this produces some linking errors for functions that were called
> > but never defined:
> >
> >
> > /usr/bin/ld: rust/rust-lang.o: in function
> > `rust_langhook_handle_option(unsigned long, char const*, long, int,
> > unsigned int, cl_option_handlers const*)':
> > /home/baal/gccrs-build/gcc/../../gccrs/gcc/rust/rust-lang.c:185:
> > undefined reference to `rust_add_search_path(char const*)'
> > /usr/bin/ld: /home/baal/gccrs-build/gcc/../../gccrs/gcc/rust/rust-
> > lang.c:213:
> > undefined reference to `rust_add_search_path(char const*)'
> > /usr/bin/ld: /home/baal/gccrs-build/gcc/../../gccrs/gcc/rust/rust-
> > lang.c:217:
> > undefined reference to `rust_add_search_path(char const*)'
> > /usr/bin/ld: rust/rust-lang.o: in function
> > `rust_langhook_post_options':
> > /home/baal/gccrs-build/gcc/../../gccrs/gcc/rust/rust-lang.c:245:
> > undefined reference to `rust_add_search_path(char const*)'
> > /usr/bin/ld: rust/rust-lang.o: in function
> > `rust_langhook_parse_file()':
> > /home/baal/gccrs-build/gcc/../../gccrs/gcc/rust/rust-lang.c:282:
> > undefined reference to `rust_parse_input_files(char const**, unsigned
> > int, bool)'
> > /usr/bin/ld: rust/rust-lang.o:/home/baal/gccrs-build/gcc/./gtype-
> > rust.h:24:
> > undefined reference to `rust_non_zero_struct'
> > collect2: error: ld returned 1 exit status
> > make[2]: *** [../../gccrs/gcc/rust/Make-lang.in:61: rust1] Error 1
> > make[2]: Leaving directory '/home/baal/gccrs-build/gcc'
> > make[1]: *** [Makefile:4319: all-gcc] Error 2
> >
> >
> > It's doesn't really help that the latest commit message
> > (3b1e76d808b9725e6ef439ae534011370e65fb85) says simply "x" and the
> > previous one, only "more". Anyhow, I'm left with those questions:
> >
> > - Considering I'm new to gcc development, what should I read before
> > getting into this?
> > - Is there any developer in particular I should talk to?
>
> As far as I can tell, this is a side-project by one gcc developer
> ("redbrain" aka Philip Herron), who appears to only work on it
> intermittently.  It may not be the best start for someone new to gcc
> development.
>
> I've CCed him on this email (hi Philip!) as I suspect he hasn't seen
> this thread (or might be on vacation).
>
> > - Is there anything else I need to know before getting started?
>
> FWIW, I'm not convinced that a rust frontend to gcc is the best
> approach - Rust has some complicated semantic-checking rules that must
> be implemented by a compiler (the "borrow checker").  Hopefully that
> code is available via a library.
>
> One approach would be something like how the GCC Go frontend works,
> which uses a library shared with the other Go compiler implementation
> to parse the code, and turn it into GCC's IR, which then goes through
> GCC's optimizer and backend.
>
> Another approach would be to build a gcc-based backend to the existing
> rust compiler, as an alternative to its LLVM-based backend, rather than
> a rust frontend to gcc.  libgccjit (despite its name) has the ability
> to generate ahead-of-time code (e.g. .o files), and has rust bindings,
> and thus could be embedded inside rustc - in theory, at least.  I'm the
> maintainer of libgccjit.  See this discussion:
>
> https://users.rust-lang.org/t/rust-front-end-to-gcc/11601
>
> Although I'm a fan of Rust, I'm deep in the middle of another gcc-
> related project, and I don't have cycles to spare to work on this
> (beyond answering libgccjit questions).
>
> Hope this is helpful and constructive
> Dave
>

  reply	other threads:[~2019-08-30 20:24 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-23 14:11 Mateus Carmo Martins de Freitas Barbosa
2019-08-27  8:10 ` Bin.Cheng
2019-08-27  9:34   ` Jonathan Wakely
2019-08-27 14:58 ` David Malcolm
2019-08-30 20:24   ` Mateus Carmo Martins de Freitas Barbosa [this message]
2022-06-27 14:51 Philip Herron
2022-06-28  7:30 ` Richard Biener
2022-07-08 17:31   ` Philip Herron
2022-07-11  7:50     ` Richard Biener
2022-07-11 15:01 ` David Edelsohn
2022-10-04 12:29   ` Philip Herron
2022-10-04 12:42     ` David Malcolm
2022-10-04 13:04       ` Jakub Jelinek
2022-10-05  9:39         ` Philip Herron
2022-10-05  9:36       ` Philip Herron

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=CACeY_cj5+MAtafALP02Ayzzz71Ojt5K1TX1s9AU-HLfNdJH0sQ@mail.gmail.com \
    --to=mateus.carmo.barbosa@usp.br \
    --cc=dmalcolm@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=redbrain@gcc.gnu.org \
    /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).