While usable, there are a few things missing in rustc_codegen_gcc:

 * Unwinding doesn't work correctly when compiling Rust code in release
mode.
 * Rustup distribution: might not be mandatory, but I guess it would be
very helpful to have an easy way to install rustc_codegen_gcc and being
able to pin to a specific version.
 * Debug info: again might not be mandatory, but would be helpful.
 * Have not been tested on many platforms: these platforms had a few
tests, so while it's possible to use Rust on them, that doesn't mean
everything works (in particular, I know that changes will be needed to
both the Rust spec file and the standard library — or its tests — for
m68k): SuperH, ARC, m68k [1] and there's currently someone
experimenting on AVR. Related to the platform support, could you please
send me a list of platforms where git is officially supported?
 * Not sure if it would be needed, but the new inline asm syntax is not
supported on architectures not supported by rustc.
 * I also expect bad compilation in some cases.

Is this simply library support in the libc crate?  That's very easy

to add.

We might also need to update the object crate.

As for the progress, we plan to have most of the patches merged for
libgccjit 14, but one important one will be missing because it's not
ready (the one for try/catch that is necessary to support Rust panics).
I expect there will be much less patches for libgccjit 15: probably
try/catch and bug fixing for the most part.
We also plan to have rustup distribution in the coming months, so
that's something that will help for adoption.
Along with rustup distribution, we plan on making architectures
currently not supported by rustc usable more easily in the coming
months.

Recently, I built and ran the tests of a dozen of the most popular
crates and all of their tests passed [2]. And rustc_codegen_gcc was
already able to build the Rust compiler in March 2022 and while not
completely working, the resulting compiler could compile a "Hello,
world!" [3].

[1] https://github.com/rust-lang/rustc_codegen_gcc/wiki
[2]
https://blog.antoyo.xyz/rustc_codegen_gcc-progress-report-26#state_of_compiling_popular_crates
[3] https://blog.antoyo.xyz/rustc_codegen_gcc-progress-report-10

On Fri, 2024-01-12 at 08:24 +0000, Sam James wrote:

"brian m. carlson" [off-list ref] writes:

quoted

[[PGP Signed Part:Undecided]]
On 2024-01-11 at 11:45:07, Sam James wrote:

quoted

Something I'm a bit concerned about is that right now, neither
rustc_codegen_gcc nor gccrs are ready for use here.

We've had trouble getting things wired up for rustc_codegen_gcc
- which is not to speak against their wonderful efforts - because
the Rust community hasn't yet figured out how to handle things
which
pure rustc supports yet. See
e.g. https://github.com/rust-lang/libc/pull/3032.

Is this simply library support in the libc crate?  That's very easy
to add.

[CC'd the rustc_codegen_gcc maintainer as well as some folks who have
tried using rustc_codegen_gcc for their distributions.]

Evidently not on the last point? ;)

Even just patching it in downstream isn't easy because you then have
to
do it for many many packages. But after that PR stalling because of
the
policy issue, there wasn't really anywhere to go, because of the
chicken-and-egg situation.

Let alone then, once the libc crate has it, going around and wiring
up
in other crates.

The discussion on the PR seems clear that the intention is to not add
it until some policy is revised/formulated? I also don't want to have
to have that debate with every crate just because rustc doesn't
support
it.

quoted

quoted

I think care should be taken in citing rustc_codegen_gcc and
gccrs
as options for alternative platforms for now. They will hopefully
be great options in the future, but they aren't today, and they
probably
won't be in the next 6 months at the least.

What specifically is missing for rust_codegen_gcc?  I know gccrs is
not
ready at the moment, but I was under the impression that
rust_codegen_gcc was at least usable.  I'm aware it requires some
patches to GCC, but distros should be able to carry those.

If rust_codegen_gcc isn't viable, then I agree we should avoid
making
Rust mandatory, but I'd like to learn more.

It's in a general state of instability. There's still *very* active
work
ongoing in libgccjit (by the rust_codegen_gcc maintainer).

I'd say "you need to patch your GCC" is probably not a good state of
affairs for using something critical like git anyway, but even then,
I'm not aware of anyone having used it to build real-world common
applications using Rust for a non-rustc-supported platform, at least
not then using those builds day-to-day.

So, even if we were willing to chase the active flurry of libgccjit
patches (which is wonderful to see!), it's a significant moving
target. In Gentoo, we're probably better-placed than most people
to be able to do that, but it's still a lot of work and it doesn't
sound very robust for us to be doing for core infrastructure.

We have a lot of packages in Gentoo - partly actually stuff in the
Python ecosystem - where we're very excited to be able to use
rust_codegen_gcc (or gccrs, whichever comes first inreadiness, surely
rust_codegen_gcc) for alt platforms, but it's just not there yet.