I have seen a certified compiler (GreenHill) compiling invalid code happily (not one relying on undefined behaviors), despite its certifications, for which even an ancient 3.x gcc complained (rightfully!)

These certifications unfortunately often are on the level of the golden shields CAs provide to customers to put on their sites as sign of trustworthiness.

So yes, blessed is a nice word for it.

I hate GreenHill C compiler as much as the next guy [insert huge rant] but the Blessed Compiler of Choice in its frozen buggy state at least usually means it's a KNOWN ENTITY. We code around the bugs, we compile in -O0 mode etc etc, we analyze the assembler output to death and so on.

I see these "certified" stamps less as "secure" and more of a huge slowing down of progress and change - which strangely can translate to more secure since you know what you are dealing with.

If I can dream, I'd take a "certified" GNU Ada, or Rust, or something over C. But that is bound to take many years to happen if ever. I think we sooner will see Rust compiled to C which is fed to something like the abominable Greenhill so security consultants can pour over the intermediate C output and put it through the abominable Greenhill.

For safety stuff I've worked on, the source had to be vetted, and then someone goes through line by line and confirms that the assembly generated for each line of code matches the source code. For C or Ada with conservative optimizations, this is fairly mechanical (and extremely boring), but means that trusting the compiler is not a requirement.

Then you must have worked on tiny software.

Blessing a compiler consists of running it on a trivial test suite and writing down the results, however bad they may be.