I have mixed feelings about the idea of a GCC frontend for Rust.
On one hand, having frontend diversity for a language helps bring new people into the language; think of the groups who can't use Rust because it doesn't support certain targets or can't integrate with their existing toolchain. There is a lot of talent that could be brought into Rust just by virtue of them being able to be included and the less barriers of entry, the better.
But on the other hand, I don't want to have to think of implementation specific behaviors, bugs, quirks, et cetera. Having an ecosystem built with thousands of people wrestling with that problem seems like a recipe for buggy software and burnout. People say that a spec would help with this aspect but I'm sceptical; a spec doesn't prevent divergence from happening, it just gives you a frame of reference for what is correct. You also don't need multiple implementations to have a spec either!
I fear that the way this is going to pan out is that we'll have multiple frontends for Rust, but the vast majority of engineers using the language will only ever think about "true" Rust: the current mainstream implementation. Issues in crates that primarily affect "alternative" Rusts will go unacknowledged, be tossed out, or have hacky patch jobs. We'll end up with either a) two separate, but high quality, ecosystems or b) one shared, lower quality ecosystem that is constantly fighting itself. I hold Rust in really high regard and it's my favorite language at the moment, so this thought is scary to me.
Though, there are a lot of smart people involved so maybe it doesn't have to be so doom and gloom. A couple of years ago I thought that cross-platform software was really messy and hard to get right but languages like Rust have the proper language features to make things like this much easier (though not perfect!). It could be that the emergence of multiple frontends could necessitate features and tooling for the Rust itself which makes all of that I said a non-issue. Maybe. Hopefully.