4 ms·

This is not the reason. We created this branch in July 2025 (GCC 12.5 was released on 11 July, 2025) and spent a year stabilizing it. A new system compiler is c

This is not the reason. We created this branch in July 2025 (GCC 12.5 was released on 11 July, 2025) and spent a year stabilizing it. A new system compiler is considered far too much of a risky, incompatible change to backport. Especially since lots of C code no longer compiles with GCC 14+ without significant changes. Each time we upgrade the system compiler, it requires extensive work to keep all of our supported architectures in working order, and adjust our code for compatibility.

ranger_danger 2mo ago
Why would the C code no longer compile if it conforms to the spec?
- stonogo 2mo ago
  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.
  - ranger_danger 2mo ago
    but if the correct standard is specified as an option, shouldn't that prevent conformant applications from failing to compile in newer versions?
    - stonogo 2mo ago
      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.
    - hulitu 2mo ago
      > shouldn't that prevent it should. It doesn't.
- seabrookmx 2mo ago
  "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.
  - ranger_danger 2mo ago
    To me, undefined behavior is by default not conformant, so that wouldn't count for the purposes of my question.
- wasting_time 2mo ago
  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.
- hulitu 2mo ago
  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.

ranger_danger 2mo ago

Why would the C code no longer compile if it conforms to the spec?

stonogo 2mo ago
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.
- ranger_danger 2mo ago
  but if the correct standard is specified as an option, shouldn't that prevent conformant applications from failing to compile in newer versions?
  - stonogo 2mo ago
    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.
  - hulitu 2mo ago
    > shouldn't that prevent it should. It doesn't.
seabrookmx 2mo ago
"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.
- ranger_danger 2mo ago
  To me, undefined behavior is by default not conformant, so that wouldn't count for the purposes of my question.
wasting_time 2mo ago
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.
hulitu 2mo ago
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.