So you have your (possibly tainted at the binary level, see "Reflections on trusting trust") compiler, let's call it [A]. You take source code to a compiler [G

So you have your (possibly tainted at the binary level, see "Reflections on trusting trust") compiler, let's call it [A]. You take source code to a compiler [GCCsource], which for the purposes of this we'll say we can trust (because at least we can read the source, IOCCC notwithstanding). The problem is that if you Compile [GCCsource] with [A] to make [GCCWithA], [GCCWithA] may be tainted if [A] is tainted. The fix is to make GCC produce reproducible builds. Then you compile [A]([GCCsource]) -> [GCCWithA] and the critical step is this: [GCCWithA]([GCCsource]) -> [GCCWithAWithA]. If [GCCWithA] makes reproducible builds, then [GCCWithX] should make bit-identical outputs with [GCCWithA]. If it doesn't, then you can tell that there are shenanigans going on. So you do [A]([GCCsource]) -> [GCCWithA]; [GCCWithA]([GCCsource]) -> [GCCWithAWithA] And then [B]([GCCsource]) -> [GCCWithB]; [GCCWithB]([GCCsource]) -> [GCCWithBWithB] You compare [GCCWithAWithA] with [GCCWithBWithB]. Now you've upped the bar. Not only does an attacker have to put a backdoor in the GCC binary, but now they have to do it to Intel's compiler, and any other compiler capable of compiling [GCCsource]. If the attacker doesn't catch all of these compilers them in exactly the same way, then it will result in a difference to the output.