There are huge amounts of existing test suites for verifying a compiler.

The majority of bugs are probably in handling of the language. Accepting everything that is included in the standard, while failing everything that is not allowed, according to the standard. The standard has huge amounts of text, and not all text is easy to read.

But when testing code optimization, it should be easy to set up tests with many, many millions of lines of reference code and make sure that the produced binaries creates the same result with or without optimization. And if a test case fails, it should be quite easy for the compiler vendor to figure out if it was nonportable or buggy code in the test case, or if the compiler produced broken code for some optimization settings. After having set up all the test code, it is just a calendar time, waiting for the results of the regression tests.

Regression-testing an RTOS is very hard, because the asynchronous events makes every test run behave differently.

A compiler should normally always produce the same results. But there are some exceptions. ARM, decided that it was too easy to test a compiler that always produces the same result. So the ARM compiler looks at the result of previous compilations when deciding how to optimize the code. So starting from empty and recompiling three times can result in three different binaries. Lucky us, that they seem to have the required time to still manage good QA on their releases.