No, because the source you can see doesn't necessarily match up with the binary you're using. The specific attack described in that paper involves multiple compiler source versions: there is a malicious one, which contains the code to inject backdoors into anything compiled using this compiler, and a clean one, which doesn't contain this code.
The attacker first compiles the malicious version, generating a compiler which inserts a backdoor into any future builds of the compiler. They then compile the clean version, using the malicious compiler. The output of this is now also malicious, even though the source code was clean - the source and binary no longer match up, but checking that is difficult. You would need to reverse engineer the binary, looking for malicious commands. The added complexity here is that if the reverse engineering tools were compiled with a malicious compiler, they could well hide the additional functionality in the binary when used.
So, an option might be to use reverse engineering tools from a completely different machine, compiled with a different version of the compiler. However, it's entirely possible that the different machine's compiler is also malicious, depending on when the original backdoor was made. For example, if they both run the same OS, they may well have the same compiler built in, which is compromised on both devices. If they don't, there may be earlier versions which were bootstrapped from a compromised compiler, or cross-compiled from a different OS which had a compromised compiler.
The only way to be sure that the whole chain is uncompromised is to manually build a binary which the processor can run, then incrementally improve this to allow extra features: you can't rely on any third party software (the text editor might insert malicious code, then hide it from view when you look at the source code, the shell might hide the file sizes of modified source files, etc...). In fact, you can't even rely on third-party hardware - the CPU might backdoor anything that looks like a compiler being built, or the RAM, or the motherboard, or the network adaptor, or any other point on the network where the compiler code or binary passed through...
Now, this is getting a bit paranoid, but in each case, as soon as there is a distinction between what source is written and what actually runs, you can't be 100% sure that the source you see and the binary that runs match up.
Note that this doesn't mean the hack has happened, but suggests that there is no way we could verify if it had without building a computer from scratch and using that to verify everything - from scratch in this case means from raw materials, for absolute certainty, without using anything which could influence the output. A hammer is probably ok, but a CNC device might be malicious, or a fab plant, or those wires, or...
puts on tin-foil hat, then realises it was made by someone else who might be compromised