Agree that secure source is required but the compiler trust issues become different with reproducible builds: you only need to trust the initial operating system binary and intermediate source code. The next compiler is built reproducibly from the old compiler.
The maliciousness in the compiler would have to be introduced in source code (which is harder) or somehow already in the initial operating system binary (disregarding bad hardware that is bad for all systems testing builds).
"you only need to trust the initial operating system binary and intermediate source code. The next compiler is built reproducibly from the old compiler."
That's kind of what I'm saying. In your model, you trust the binaries and files you received in the OS to run with a bunch in kernel mode. You don't trust the compiler. In my model, I trust the semi-privileged compiler I received with the OS since I already trust all the OS code. An attacker that could subvert the compiler would prefer subverting the OS instead or in addition to compiler. Then, they could possible avoid any solutions I have such as double compilation. If I use a stock scheme, they might even subvert it.
If you're not trusting the repo, you have much bigger problems than reproducible builds can solve. At the least, you will be doing reproducible builds plus a bunch of downloads from mirrors, hash/sig checks, comparisons, etc.
The maliciousness in the compiler would have to be introduced in source code (which is harder) or somehow already in the initial operating system binary (disregarding bad hardware that is bad for all systems testing builds).