
GCC 7.5 - edelsohn
https://gcc.gnu.org/ml/gcc/2019-11/msg00099.html
======
TheSoftwareGuy
If anyone else was questioning their memory, thinking GCC 9.x had already been
released, see this:

>This is also the last release from the GCC 7 branch which will receive no
further fixes from now on. GCC continues to be maintained on the GCC 8 and GCC
9 branches and the development trunk.

~~~
mojuba
GCC 9.x? I'm stuck in the time when GCC 2.95 was a (buggy) thing everyone
relied on until 4.x stabilized. Never used GCC ever since.

GCC is an important piece of software, probably as important as the Linux
kernel, but by now I presume it should have become a gigantic pile of outdated
and barely maintainable code. Unless I'm wrong of course!

~~~
goalieca
llvm really gave gcc a kick in the pants. It's now blazing forward!

~~~
mojuba
It did, though I think the support of languages and HW platforms is still a
bit limited compared to gcc?

------
vortico
How does the GCC project afford to fix "more than 215 bugs" on an old branch?
Do they cherry pick commits from 8 and 9? Do they fix bugs on the 7 branch and
then cherry pick them into 8 and 9?

~~~
Reason077
Yes. Fixes are made on HEAD and applied/back-ported to the release branches
where appropriate.

------
not2b
There seems to be a lot of confusion in the comments here. At one time, GCC
had three-part version numbers: major.minor.patchlevel. Starting with gcc 5,
they switched to a two-part scheme: just major.patchlevel. 7.5 adds nothing
but bug fixes to 7.4, there are no new features. That's why the changes page
pointed to on gcc.gnu.org only describes gcc7 changes.

[https://gcc.gnu.org/develop.html#timeline](https://gcc.gnu.org/develop.html#timeline)
gives a good picture of how gcc releases work.

------
WalterGR
I went looking for release notes. Doesn't look like they exist, per se.

[https://gcc.gnu.org/gcc-7/changes.html](https://gcc.gnu.org/gcc-7/changes.html)
is about the entire GNU 7 series, but it's not broken down by release. The
list of tickets closed is mentioned at the bottom:

> GCC 7.5: This is the [
> [https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED...](https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=7.5)
> ](list of problem reports (PRs)) from GCC's bug tracking system that are
> known to be fixed in the 7.5 release. This list might not be complete (that
> is, it is possible that some PRs that have been fixed are not listed here).

------
tannhaeuser
Am I the only one unable to keep pace with compiler development? For some code
on x86/64 I'm still using gcc 4.7, and a cursory test with gcc 5 (or even gcc
4.9) resulted in compile-time errors I hadn't time to look into. Maybe it's
just a compiler or linker flag, which tbh is something that's gone out of
control. Given the intimacy gcc has with glibc and the Linux kernel, in turn,
what are folks using for a stable build environment that just doesn't need to
change all the time because the software does what it's supposed to do, and
doesn't need, nor benefits from high-energy agility? I know there are
occasionally new targets and optimizations, but wasn't C a language supposed
to be easy for writing a compiler for in a couple months? Well ok the same
could said about a Unix kernel I guess. I mean I appreciate the gcc project
for providing backports, but the new gcc versioning scheme makes release
numbering kindof arbitrary, and can be interpreted to give a finger to older
software especially in C-land.

~~~
wahern
Without seeing the errors it's difficult to say. GCC 4.7 is really old (2012),
and there are only a few areas I can think of off the top of my head that
might trigger such problems, mostly related to C11 support and buggy feature
detection or erroneous usages by older code, such as static_assert definitions
or tests, possibly directly or indirectly related to older glibc headers.
Interestingly, most of the C-related changes from 4.7 to 4.9 _are_ related to
C11.

GCC has been less aggressive compared to clang in adding diagnostics to -Wall
that trigger on correct code; -Wno-missing-field-initializers and -Wno-
override-init come to mind, but those predate 4.7. -Wexpansion-to-defined is
super annoying, but that came much later (GCC 8?), and strictly speaking it
triggers on undefined behavior--it's just that the undefined behavior was
extremely convenient, pre-dated GCC, reliably supported (at least for the most
common and possibly only usages) on almost all if not all major compilers, and
is the only possible approach for writing lazy feature detection macros that
can be defined in library headers without include'ing possibly unused headers,
polluting the namespace.

