On Fri, 2019-12-27 at 10:53 -0500, David Edelsohn wrote:
> > > > > > John Paul Adrian Glaubitz wrote:
> > The programming language Rust has become very popular over the past
> > few years
> > with many projects rewriting parts of their codebase in that
> > language. While
> > these rewrites often make the code perform faster and potentially
> > safer, using
> > Rust makes these projects less portable as Rust is limited to the
> > architectures
> > supported by LLVM which are less than the ones supported by GCC.
> > 
> > For this reason, people have been asking for a Rust frontend for
> > GCC similar to
> > the one for Go. Now, there are actually two independent
> > implementation of a Rust
> > frontend for GCC [1, 2] being developed and I was wondering whether
> > it would be
> > desirable to help this development with a Bountysource campaign?
> > 
> > I'm asking because I'm not sure whether GCC upstream would be okay
> > having a Rust
> > frontend in GCC at all and, if yes, it would be okay to have a
> > Bountysource campaign
> > for that project?
> > 
> > I personally like the idea of a Rust frontend for GCC very much as
> > I expect more
> > software projects in the future to adopt Rust and I would like to
> > be able to build
> > and use these projects on architectures that LLVM doesn't support
> > yet (and might
> > not even in the future).
> > 
> > Due to the popularity of Rust and the desire of the community for
> > an independent
> > implementation, I expect the Bountysource campaign to be rather
> > successful.
> 
> The earlier, public discussions about a Rust front-end were open and
> welcoming.  The GCC Community and GCC Steering Committee would be
> happy to consider a Rust front-end that can be contributed and
> accepted into GCC and is maintainable.  As David Malcolm previously
> commented, something similar to the adaptor for GCC Go or an adaptor
> for rustc seems the most productive approach.  GCC gains nothing by
> creating unnecessary barriers to support for popular programming
> languages.

Indeed; another approach might be a libgccjit backend to the existing
rustc compiler - that would live in the rustc compiler, though I guess
(rust bindings to libgccjit already exist, IIRC).

Dave

Reply via email to