hmm, we may have miscommunicated. knowing that two compilers (or two toolsets) are *independent* is no simple feat indeed, for all the reasons you named, and then some. e.g., many many years ago, gcc used to borrow (by bringing into libgcc) implementations of long integer and float operations from whatever compiler you used to build it. this was a clever trick for native builds (not so much for crosses), but it have the side effect of building blobs of unclear provenance into libgcc, and thus potentially into binaries built by the compiler, and that's very down-to-earth, mean-no-ill behavior (as opposed to malicious esoteric attacks), but it is undesirable for various reasons.

now, since we're talking software freedom philosophy rather than security issues, please allow me to bring some further thoughts onto the table. if you're writing, compiling, debugging and fixing a program so that it does your computing as you wish, and not once do you notice these hidden blobs, or hit a situation in which they'd be activated so as to deviate the program's behavior from what's expected from its sources, are you not getting your computing done as you wish regardless of the hidden blobs? are you not indeed in control of that computing? there are some security risks and landmines hiding in there, I'm not denying that, just trying to un-conflate freedom and security.

so the hidden blobs pose an obstacle to learning details of the binary, but to studying the source code?