antoyo

Well, LTO works in many cases, so it's not completely broken. I managed to do a refactoring in this PR, but I'm not entirely satisfied with the results yet (it prints stuff to stderr when LTO is not supported by the gcc installation). I have an idea to workaround this in order to land this PR which should help me continue fixing the issues we have with LTO.

LTO is very complex, though, so this is why it's taking time to move forward on this (same for unwinding support which also works in many cases, but not all).

Well, we can generate code for targets not supported by LLVM, but it is not trivial to setup (we hope to get rustup support in the coming months to make this easier) and most GCC targets won't pass as many tests as x86-64 with rustc_codegen_gcc. There's some info in the wiki about some targets that people tried.

It is an optional goal for the Google Summer of Code to bootstrap the rust compiler on other platforms, so we might be able to get a working rustc for new platforms by the end of the summer.

Oh, sorry for the confusion: this is about rustc_codegen_gcc which is a codegen plugin for rustc that uses libgccjit to generate the object files via GCC instead of LLVM, so it still requires rustc. There's another project that is a GCC frontend, called gccrs. Also, bootstrap is overloaded: in this case, a full bootstrap means that we can compile the Rust compiler with rustc_codegen_gcc, producing a stage-2 compiler, then recompile the Rust compiler with this stage-2 compiler to get a stage-3 compiler and those 2 compares as equal.

What do you think it means?