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