GCC and binutils updates for buster

GCC 8 is available in testing/unstable, and upstream is approaching the first
point release.  I am planning to make GCC 8 the default at the end of the week
(gdc and gccgo already point to GCC 8).  Most runtime libraries built from GCC
are already used in the version built from GCC 8, so I don't expect runtime
incompatibilities anymore.  There is one more transistion involved, bumping the
libgfortran version.

A pre-release version of binutils 2.31 is in testing now, and the final 2.31
release in unstable.

These are the major versions for the upcoming buster release, still planning
updates to a potential GCC 8.3.0 (estimated Jan 2019) release and binutils
2.31.1 release, or doing equivalent updates from the release branches.

There are still a bunch of build failures triggered by GCC 8 [1], so fixing
these should get some priority now. See [2] for changes in GCC 8, and the
porting guide [3].  I'll be at DebCamp for the second half of the week, and at
DebConf, so if there is interest for bug squashing sessions, feel free to grab
me, and we can schedule such sessions on a short notice.

GCC 5 and GCC 6 are going away, and I am planning the same with GCC 7 as soon as
there are upstream kernel and glibc releases which are released after the GCC
8.1.0 release from April.

The Debian release team lists toolchain support for our release architectures,
and according to [4], the amd64, i386, armel, armhf, arm64 architectures are
supported as primary architectures, and s390x is supported as a secondary
architectures.  Some notes on other candidates for release architectures:

 - armel: The armv4t default isn't used very much anymore, and we had
   issues in the past.

 - armhf: While arm-linux-gnueabihf is not explicitly listed as a primary
   architecture, I'm told that the arm-linux-armeabi triplet covers the
   hard float variants as well.

 - ppc64el: Not documented as primary architecture, but according to the
   backend maintainers the powerpc64-linux-gnu triplet includes the le variant.

 - mips*: There is no support for any mips-linux target either as a primary
   or secondary release architecture (only bare metal), which matches the
   experience with mips specific issues for the past Debian releases.

I understand that port maintainers want to have their port included as a release
architecture, however it becomes a burden if neither the upstream nor the Debian
port maintainers can keep up with the general upstream development. Maybe we
need something in between the alternatives of being a release arch or not,
having the benefit of packages in testing/stable, but not being supported in a
release.

Matthias

[1]
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-8;[email protected]
[2] https://gcc.gnu.org/gcc-8/changes.html
[3] https://gcc.gnu.org/gcc-8/porting_to.html
[4] https://gcc.gnu.org/gcc-8/criteria.html

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE1WVxuIqLuvFAv2PWvX6qYHePpvUFAltMwOcACgkQvX6qYHeP
pvVwuQ//T/e9MBaU1NCtBz66qrUN7fhJJ9i8QStzXIP57Ta+wVaMQGZBUXwqPgBA
Zj8Ui/KJ0BmolpWRd1qygOZuNHBdvUhKkXfpCem7K9XqFe0X8Dz3NgZkzWUKkhss
8GZ6VGnKYaMgjWDoahmHPnlJ8xpfZbB05wCnRQa5wr5eym/4jWJ3v993NLRQm9yH
oFN+coWaay7lZBaarbilIY8Wr3rVUBrg0ZWwsGQXJbFWTRPgUpII2Qcatkx7axt4
f/XSVU1db9XoOS5XsnTbkCHl83UFt4UjvxCp6nZWTeOEI0im3CyacnJ7uMoG+oS9
Im0qcfD5LCZZZ2WG8cQF67UKCEkhhA6GLbXTNDoeF6jZ9KzSNiEdf47zSuaxQKTm
cyI6Ios8lIR5GYBpyMgkSscfJ9Zm9b0ALPtxBTOWIE8tXjYtmZDyTzZeOaSEnFgj
23Mtj4vvVBAbVCUtAB9Bd6Nmf568FLyV0nlExkI68WY0mxVjNMUkTwjoymD6PaRw
S+aALXTSCerg1hxdJOB+r7KK3XLWgLvkuV3QW0vK9kn7r1bkHq29klAEzkySJU9n
U1Fs72CfSR+QpKDSBuUsGbOec+vBTXlRr1nm04kgOhpoZNFB3qTU/7q07MjS5rni
tCsZaj56oOFXCE9K8XfRCm0VNP96+c61aWgcPRJr/lJN3qtGbK4=
=9Plu
-----END PGP SIGNATURE-----