I have given some thought to this kind of thing, and one thing I realized is that the limits of the trusting trust attack can be exploited as well. Let's support you only have one compiler. Now, it is going to try to insert the worm into any compiler it compiles, right? The problem is that it must be able to detect that it is actually compiling a compiler.
This, however, is not a decidable problem. It is possible to construct a program that will fool the worm and thus you can create a compiler that you know you can trust for this test. It will probably be a hard compiler to use, but you will need it at most twice -- once to check for an attack, and if there is an attack once more to bootstrap a clean compiler.
But in order to create a disguised compiler, you need to know what method a compromised system uses to decide whether something is a compiler.
i.e., you actually have to have an example of a compromised compiler, which pretty much solves the problem in the first place.
If you decidedly don't-trust the only compiler on your system, and don't trust outside sources, the only solution is to hand-assemble a new compiler on the system, and hope that at least the hardware is trustworthy. which it isn't, necessarily.
This, however, is not a decidable problem. It is possible to construct a program that will fool the worm and thus you can create a compiler that you know you can trust for this test. It will probably be a hard compiler to use, but you will need it at most twice -- once to check for an attack, and if there is an attack once more to bootstrap a clean compiler.