"The spec" is loose in places and is full of undefined behavior which can change from compiler to compiler. Very low level code tends to hit these types of issues much more than application code would. But these types of issues are even common in large userspace codebases.

To me, undefined behavior is by default not conformant, so that wouldn't count for the purposes of my question.

There is more than one C specification, and with each new release of GCC several things that used to emit warnings are newly treated as errors.

but if the correct standard is specified as an option, shouldn't that prevent conformant applications from failing to compile in newer versions?

Sure, that's one approach. Testing those changes takes time when you're working on a whole operating system and a ports tree. More time than cutting a new gcc release, as it turns out.

> shouldn't that prevent

it should. It doesn't.

You sort of answered your own question.

Another reason is compiling with -Werror and hitting new warnings.

Also, the version of the spec changes with almost every major release.

Because, for some reason, someone at gcc decided that some warnings shall be treated as errors. Good luck finding out which those are and which flags you need as a countermeasure. Of course it has documentation. Of course it is useless.