Flawed logic. C++ doesn't have a corporate sponsor either, and yet it has a native compiler on Windows.
Multiple vendors pay good money to develop compliant C++ compilers for many of the platforms that we use.
The two main challenges I see for C are the competition with C++ and faster hardware.
Most "C compilers" are actually C++ compilers running in a "C mode". The trouble is that most of the corporate sponsors care more about being compliant with the latest C++ standard than being compliant with the latest C standard.
And because C++ is slightly more typesafe (strict aliasing), those optimizers can do more for C++ code than for C. So despite the more complex language, C++ can be marginally faster (~1%).
Probably not even that. In the tiny number of cases where strict aliasing buys you anything at all (which on modern out-of-order hardware it almost never does), it's around the same order of magnitude as the performance that you lose in C++ due to maintaining exception handling information. There's really nothing between C and C++ given the same code these days. In practice, most of the performance gains in C++ come from metaprogramming.
Which gets us to the faster hardware: how often is that performance even needed?
For the vast majority of "embedded" devices that I own, the main performance impact isn't CPU speed, it's battery life. A program which gets its job done as quickly as possible and then puts the CPU into an idle state is far more desirable than one which is perceptually just as responsive but wears down the battery faster.